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FOREWORD 


The  Medical  Instrumentation  Linkage  System  (MILS)  has  been  documented  in  several  volumes 
to  serve  a  broad  range  of  reader  interests.  This  Final  Report  presents  an  overview  of  the 
system,  the  task,  the  hardware  and  the  programming.  It  provides  an  introduction  for  readers 
desiring  to  gain  a  more  detailed  knowledge  of  the  system. 

The  System  Description,  Volume  I,  describes  MILS  design  concepts.  Major  categories  are 
included  to  describe  laboratory  applications,  ward  communications,  multiprogramming  con¬ 
cepts  and  data  base  organization.  This  volume  is  intended  to  serve  the  technical  needs  of 
computer  system  analysts  and  laboratory  personnel  interested  in  function  specifics. 

Operating  Procedures,  Volume  n,  provide  the  instructions  for  all  areas  of  system  operation- 
admissions,  laboratory  functions,  ward  communications  and  the  computer  room.  The  objec¬ 
tive  of  this  volume  is  to  provide  a  personnel  training  aid  as  well  as  a  procedure  reference 
for  the  non- routine  situations. 

Program  Documentation,  Volume  III,  presents  the  technical  detail  for  each  programmed 
module  in  the  system.  This  volume  provides  the  necessary  reference  material  for  Analysts 
and  Programmers  desiring  to  modify  the  system  software.  Functional  descriptions,  detailed 
flow  charts,  and  technical  narratives  for  each  module  are  documented.  Listing  of  the  source 
program  code  is  included  as  an  integral  part  of  this  documentation. 

Installation,  Volume  IV,  describes  the  physical  aspects  of  MILS  facility  at  William  Beaumont 
General  Hospital.  The  equipment  placed  in  the  various  hospital  locations  is  itemized.  Physi¬ 
cal  planning  data  including  space,  environmental  control  and  electrical  specifications  are 
included.  The  cabling,  the  instrument  interfaces  and  the  operator  control  boxes  are  included 
in  this  section.  Installation  and  checkout  instructions  are  included  as  an  aid  in  trouble¬ 
shooting  and  maintaining  the  online  data  acquisition  facility. 
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Section  1. 


INTRODUCTION 


The  Medical  Instrumentation  Linkage  System  (MILS)  is  a  computerized  clinical  laboratory 
system  with  direct,  2-way  communication  to  hospital  wards.  The  purpose  of  the  MILS  Project 
was  to  develop  an  operational  laboratory  information  system  to  serve  as  a  prototype  for  the 
U.S.  Army  Class  II  hospitals.  The  development  and  implementation  has  been  conducted  at 
William  Beaumont  General  Hospital,  El  Paso,  Texas. 

The  objectives  of  this  development  were  directed  toward  improvements  in  patient  care  through 
implementation  of  new  laboratory  information  handling  concepts.  Reduction  in  time  from 
receipt  of  request  to  reporting  of  results,  reduction  in  clerical  and  computational  errors, 
improved  specimen  accounting  practices,  increased  information  for  laboratory  management, 
and  a  flexibility  for  change  and  growth  were  goals  established  for  the  project. 

The  approach  which  was  taken  was  to  install  a  centralized  computer  system  and  to  develop  a 
software  system  capable  of  supporting  multiple  functions  in  an  online,  realtime  manner.  The 
1800  Data  Acquisition  and  Control  System  was  selected  as  the  central  system.  Its  hardware 
characteristics  included  the  features  necessary  for  data  acquisition  (digital  and  analog  I/O), 
simultaneous  operations  (hardware  priority  interrupts  and  interval  timers)  and  multiple 
peripherals  operating  at  various  performance  levels  (disk,  tape,  card,  line  printers,  terminals, 
optical  reader).  The  MPX  (Multiprogramming  Executive)  Operating  System  provided  the  soft¬ 
ware  sophistications  necessary  to  schedule  and  control  the  multiple  operations  and  complex 
data  flows. 

The  system  was  designed  to  provide  a  complete  "demand-response,'1  interactive  mode  of 
operation.  Operator  terminals  were  installed  at  the  laboratory  work  stations.  Easy-to-use 
conversational  methods  were  adopted  to  minimize  training  requirements.  Instruments,  inter¬ 
faced  directly  to  the  central  processor,  provide  online  data  acquisition.  Offline  test  results 
are  entered  to  provide  complete  laboratory  records  in  the  system.  Inpatients  and  outpatients 
are  supported  so  that  complete  specimen  accounting,  patient  reporting,  and  laboratory  reports 
are  accommodated.  Communication  terminals  provide  online  immediate  (query)  access  to 
laboratory  results,  remote  online  entry  of  test  requests,  and  remote  printing  of  test  results. 

Special  consideration  was  given  to  the  structure  of  the  data  base  so  that  the  desired  response 
criteria  could  be  fulfilled.  A  data  base  organization  has  been  designed  to  support  collection, 
inquiry  and  retrieval  of  data  in  various  forms  from  multiple  sources.  The  files  were  struc¬ 
tured  and  indexed  so  that  patient  records,  specimens  in  the  laboratory  and  laboratory  results 
may  be  interrogated  at  any  time  and  retrieved  for  truly  current  information.  Patient  History 
Results,  Laboratory  Statistics,  Quality  Control,  and  Patient  Census  are  typical  of  other  files 
which  may  be  accessed  for  realtime  reporting  needs,  A  patient  orientation  is  used  for  the 
storage  and  accessing  (location  and  retrieval)  of  laboratory  results.  This  patient  identification 
is  "chained"  to  corresponding  laboratory  records.  Other  chains  can  easily  be  appended  if 
other  patient  oriented  data  were  to  be  included  in  the  file  (radiology  records,  patient  history, 
physical  examination  results,  etc.). 

The  system  interacts  with  each  step  in  the  laboratory  test  cycle— Admission  (if  inpatient), 

Test  Requisition,  Laboratory  Test  Performance,  Laboratory  Review  and  Return  of  Results 
(Figure  1).  Although  the  process  is  cyclical  for  each  specimen,  the  many  sources  of  requisi¬ 
tions  and  the  variations  in  test  complexity  dictate  that  every  step  in  the  basic  cycle  be  in 
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Figure  1.  Laboratory  Data  Flow  Basic  Test  Cycle 


2 


operation  at  the  same  time.  Each  transaction  (instrument  output,  patient  admission,  test 
requisition,  etc)  is  processed  on  an  "in-line"  basis  as  the  data  is  available.  Pertinent  files 
are  updated  as  each  transaction  is  completed  wi.,h  no  "batching."  Therefore,  patient,  test,  and 
specimen  data  is  always  current  and  the  information  provided  in  response  to  inquiries  (l«ho- 
latory  or  ward)  reflect  the  latest  status.  Interim  or  working  reports  prepared  for  the  wards 
or  laboratory  similarly  reflect  the  status  as  of  the  time  of  printing. 
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Section  2.  MILS  FUNCTIONS 


The  Basic  Test  Cycle  requires  a  variety  of  int'oi  mati on-handling  functions.  These  system 
functions  have  been  developed  as  discussed  below  to  support  these  needs. 


2.1  ADMISSION  AND  DISCHARGE 

Admission  and  discharge  of  inpatients  is  performed  throughout  the  day.  Terminal  cable  length 
accommodates  installation  in  the  Admissions  Office.  Patient  identification  is  entered  into 
system  files  using  interactive,  conversational  terminal  'echniques  as  patients  are  admitted. 
This  patient  is  online  (with  his  identification  5n  the  system  files,  available  for  processing) 
until  he  is  discharged.  Entry  of  patient  identification  in  this  manner  establishes  a  master 
record  for  support  of  immediate  lab  requi.  .tions,  Changes  may  be  made  in  the  identification 
data  after  the  initial  entry  has  been  established.  When  a  patient  is  discharged  his  complete 
laboratory  record  is  transferred  to  magnetic  cape. 


2.2  TEST  REQUISITIONS 

Two  modes  of  entering  requests  for  laboratory  tests  are  supported— mark  sensing  and  type¬ 
writer  keyboard.  The  mark  sense  sheet  is  used  for  inpatients  whese  identification  is  on  file. 

The  desired  tests  and  patient's  ID  number  (Social  Security  Number)  are  marked  with  a  stan¬ 
dard  number  "2"  pencil.  Test  sheets  are  designed  to  record  results  manually  if  a  backup 
mode  of  operation  is  in  use.  Outpatient  requests  are  specified  on  the  typewriter  terminal. 
Complete  identification  consisting  of  name,  SSN,  age,  and  sex  are  typed  as  are  clinic  and 
doctor's  numbers  ar.d  the  desired  tests.  Optional  entries  of  patient  rank,  organization  or  duty 
status  may  be  included.  When  entered  this  data  is  carried  forward  and  printed  on  the  laboratory 
report. 


2.3  LABEL  GENERATION 

Labels  are  generated  for  both  inpatients  and  outpatients.  Use  of  a  common  label  provides  a 
uniform  document  for  laboratory  personnel.  The  label  is  a  4"  x  8-1/2"  label  stock  with  10 
individually  removable  gummed  tabs.  The  system  assigns  the  accession  number  and  prints  the 
same  number  on  all  tabs  to  accommodate  multiple  tubes  and  separation  steps.  The  patient's 
name,  identification,  location,  age,  sex,  and  the  requested  tests  are  printed  on  this  label.  The 
specimen,  type  of  container,  and  the  volume  are  determined  by  the  system  and  printed  on  the 
label. 


2.4  COLLECTION  SCHEDULE 

Requisitions  entering  the  system  may  be  marked  for  collection.  These  are  retained  in  a  col¬ 
lection  file  until  the  next  printing  of  the  collection  schedule.  Collections  may  be  performed 
once  each  morning  or  several  times  throughout  the  day.  The  standard  laboratory  label  is 
printed  for  the  collection.  These  labels  are  printed  in  ward  and  bed  number  sequence  to  elim¬ 
inate  manual  sorting  and  assist  the  collectors  on  ward  rounds.  A  terminal  entry’  when  collec¬ 
tion  is  complete  makes  the  collected  specimens  available  for  laboratory  scheduling.  Specimens 
may  be  indicated  as  not  collected.  A  notification  of  a  late  collection  is  supported  by  the  system. 


2.5  PROCEDURE  ASSIGNMENTS 


Each  test  request  entered  in  the  system  is  assigned  a  procedure  for  result  detennination. 
Technicians  have  the  flexibility  to  override  a  system  assigned  procedure,  perform  the  test 
manually  and  enter  results.  Each  test  is  individually  assigned  a  procedure.  Procedures  may 
be  assigned  uniquely  for  patient  category  (adult,  infant,  or  child)  or  by  type  of  request  (STAT 
or  Routine).  A  single  test  which  is  a  member  of  a  multi-test  instrument  may  be  assigned  to 
be  performed  on  the  instrument  or  to  be  performed  using  a  manual  method.  When  a  request 
for  a  singl?  test  is  performed  on  a  multi-test  instrument,  only  the  specific  request  is  reported, 
although  the  other  results  are  stored  in  the  system  and  can  be  reported  if  desired. 


2.6  LOAD  LIST 

Load  lists  are  associated  with  the  online  instrurr  .its  and  are  printed  on  the  laboratory  term¬ 
inals  when  requested.  A  load  list  provides  a  sc’  dule  of  all  work  to  be  performed  on  the  speci¬ 
fied  instrument  (SMA  12/60,  Glu/Bun,  etc.).  Positions  of  standards,  controls,  water  blanks,  and 
patient  specimens  are  indicated.  Position  of  these  items  is  controlled  by  the  procedure  file, 
which  is  l’eadily  modified.  Patient  names  are  included  on  this  report.  The  technologist  follows 
this  list  In  arranging  his  turntable.  He  may  make  changes  in  this  assigned  list  using  laboratory 
terminals.  The  technologist  initiates  system  data  acquisition  for  each  instrument  by  using  a 
control  box  adjacent  to  his  instrument.  This  device  has  easy-to-use  push  buttons  for  start/stop 
and  status  lights  to  show  data  acquisition  in  process  and  possible  trouble  alerts.  Results  are 
error  checked,  converted  to  concentration  units  and  stored.  On  request,  results  are  printed 
on  the  laboratory  terminal.  The  technologist  verifies  this  list  (he  has  delete,  modify,  and 
rerun  capabilities)  making  the  results  available  for  reports. 


2.7  WORK  LIST 

A  work  list  is  printed  on  the  laboratory  terminal  when  requested  by  laboratory  personnel. 

This  list  shows  the  pending  work  for  tests  performed  on  other  than  online  instruments.  The 
technologist  indicates  a  specific  test  or  battery  name  (e.g.,  NA,  CA,  BLGAS,  LYTES,  TRP). 
The  accession  number  and  patient's  name  are  printed  for  all  pending  requisitions  in  ihe  speci¬ 
fied  category.  STATs  receive  special  identification  and  are  printed  in  red  for  rapid  detection. 


2.8  ONLINE  DATA  ACQUISITION 

Direct  data  transmission  has  been  developed  for  eight  types  of  laboratory  instrumentation. 
Additionally,  direct  operator  communication  is  provided  via  control  boxes  at  the  instrument 
location.  The  instrumentation  which  is  online  includes:  SMA/12/G0,  Coulter  Counter,  single 
and  dual  channel  autoanaly/.ers,  fibrometer,  differential  counter,  flame  photometer,  spectro- 
photofluorometer,  and  a  digital  data  entry  device. 


2.9  OFFLINE  RESULTS 

Test  results  obtained  through  use  of  offline  instruments  are  accepted  by  the  system.  Mark 
sense  sheets  are  used  to  record  the  test  results  and  corresponding  accession  number.  These 
results  may  be  processed  at  any  time  individually  (e.g.,  STATS)  or  in  small  batches  as  desired 
by  laboratory  personnel.  The  results,  recorded  by  the  laboratory  personnel,  bypass  a  keypunch 
or  other  data  preparation  step.  In  the  technologist's  presence,  results  are  computer-checked 
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as  they  are  read  in.  Any  errors  detected  can  be  corrected  immediately  and  reprocessed.  A 
printout  of  the  results  entered  is  provided  on  request.  Override  capability  is  provided  if  the 
user  detects  an  error  on  the  printout.  This  report  provides  the  laboratory  technician  with  his 
hard  copy  record  of  test  results.  Eleven  mark  sense  sheets  have  been  devised  to  accom¬ 
modate  the  wide  variety  of  test  formats.  Both  numeric  and  text  information  appear  on  patient 
reports  depending  on  the  type  of  result  a  test  requires.  The  common  numeric  results  are 
recorded  on  the  2,  3,  4  digit  result  sheet.  The  results  of  an  urinalysis  test  including  selection 
of  text  results  are  recorded  on  a  routine  urinalysis  sheet.  Other  manual  result  sheets  are 
used  for  miscellaneous  quantitative  results  (several  numeric  answers  for  one  test;  blood  gases, 
e.g.),  selection  from  a  list  of  options  (negative,  increased,  decreased,  or  normal;  Sulkowitch, 
e.g.),  or  combinations  of  numeric  results  and  selection  from  a  list  for  Body  Fluid  counts. 

Every  laboratory  test  may  be  reported  using  the  1231  mark  sense  reader,  thus  providing  back¬ 
up  for  on-line  instrumentation. 


2.10  WORKLOAD  REPORT 

This  report  is  printed  on  request  on  a  laboratory  terminal.  For  the  specified  laboratory  group 
the  number  of  tests  requested,  the  number  in  process,  and  the  number  completed  are  shown. 

It  provides  a  current  status  of  the  work  load  for  each  laboratory  section. 


2.11  SPECIMEN  RETENTION  REPORT 

This  report  may  be  printed  at  any  time  and  is  printed  on  the  line  printer.  It  shows  the  status 
of  each  specimen  in  the  laboratory.  This  provides  the  laboratory  supervisor  with  the  overall 
status  of  active  specimens.  It  further  permits  laboratory  personnel  to  dispose  of  specimens 
with  confidence  that  the  work  is  complete. 
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2,12  DAILY  LOG 

The  daily  log  tabulates  all  test  results  by  patient.  It  is  segmented  by  laboratory  groups  with 
inpatients  separate  from  outpatients.  It  shows  laboratory  accession  number,  patient  ID, 
patient  location,  test  name  and  test  results. 


2.13  QUALITY  CONTROL  REPORT-ONLINE  INSTRUMENTS 

The  Quality  Control  Values  are  automatically  extracted  and  placed  in  the  Quality  Control  File. 
The  Quality  Control  Report  is  printed  each  day  in  a  cumulative  format  showing  status  for  the 
complete  month.  Cumulative  statistics  are  maintained  for  the  current  month  and  for  the  life 
of  the  specific  control.  The  daily  result  is  compared  to  an  historical  mean  and  the  number  of 
standard  dev  iations  .s  indicated  by  an  appropriate  number  of  asterisks  on  the  report. 


2.14  QUALITY  CONTROL  REPORT-OFFLINE  INSTRUMENTS 

Control  values  are  manually  tabulated  .and  keypunched  for  offline  Instruments.  The  cumulative 
report  format  is  printed  daily  to  eliminate  manual  charting.  In  this  ^.nse  the  file  is  maintained 
in  punched  cards. 


2.15  DAILY  INPATIENT  CUMULATIVE  REPORTS 


Cumulative  reports  are  printed  in  two  formats.  Numeric  results  and  alphabetic  results 
expressed  in  five  characters  or  less  are  formatted  with  days  across  the  top  and  the  test 
names  on  the  left.  Normal  ranges  are  shown  and  tests  outside  of  this  range  are  flagged  with 
an  asterisk.  Tests  which  cannot  be  reported  in  this  format  are  printed  with  dates  and  tests 
arranged  vertically  on  the  sheet.  Up  to  seven  days  of  cumulative  information  is  presented. 
Reports  are  printed  in  ward/bed  sequence  to  facilitate  distribution. 


2.16  DAILY  OUTPATIENT  REPORT 

The  outpatient  report  contains  laboratory  results  for  one  day.  Normals  are  printed  and 
flagged  with  an  asterisk  when  outside  the  range.  The  report  is  printed  in  clinic/doctor  number 
sequence. 


2.17  MIDDAY  PATIENT  REPORTS  (WARD  REPORTS) 

Reports  are  printed  on  request.  Status  of  active  laboratory  work  is  shown.  The  report  may  be 
printed  as  frequently  as  desired  for  all  wards  or  for  specific  wards  as  designated  by  the  tech¬ 
nologist.  Midday  outpatient  reports  may  be  printed  as  needed. 


2.18  FILE  MAINTENANCE 

File  maintenance  programs  perform  the  record-keeping  function  which  allows  "roll-over" 
processing  from  day  to  day— i.e.,  incomplete  work  remains  active  and  is  scheduled  on  the  next 
request.  Daily  removal  and  repacking  of  information  reduces  overall  file  requirements.  A  file 
utilization  printout  provides  a  status  of  space  available  in  system  files.  Inactive  patient  records 
(inpatients  being  discharged  or  outpatient  with  laboratory  work  complete)  are  written  on 
industry-compatible  magnetic  tape. 


2.19  LABORATORY  EVENT  TRAIL 

As  laboratory  personnel  perform  key  functions,  these  events  are  recorded  on  the  console 
termi.  al.  This  provides  a  centralized  audit  print  out  of  overall  laboratory  status.  Instruments 
active  or  runs  completed  but  not  verified  can  be  quickly  established.  The  status  of  overall  ward 
rounds  is  readily  apparent.  The  times  of  key  laboratory  event  completion  are  available  for 
laboratory  supervisor  review  at  any  time  throughout  the  day. 


2.20  LABORATORY  STATISTICS 

A  daily  activity  summary  provides  the  number  of  requests,  completed,  incomplete  and  STATs 
for  each  test.  Accumulative  inpatient  vs  outpatient  workload  figures  are  provided.  History 
reports  are  printed  for  a  variable  number  of  months  up  to  12  and  include  ASCP  (American 
Society  of  Clinical  Pathologists)  factors  and  extensions. 


8 


2.21  WARD  COMMUNICATIONS 


Terminals  ha,re  been  installed  at  nursing  stations  in  hospital  wards.  An  optical  image  unit  with 
a  light  pen  type  probe  is  used  for  input  functions.  A  typewriter  communications  terminal  prints 
computer  outputs.  Authorized  personnel  may  request  laboratory  tests  or  retrieve  test  results 
(either  current  or  historical).  Responses  to  laboratory  inquiries  contain  the  up-to-the  minute 
status  of  laboratory  work.  STAT  results  are  transmitted  directly  when  completed  in  the  labo¬ 
ratory.  Patient  reassignments  may  be  made  directly  from  the  ward  terminal. 


Section  3 


EQUIPMENT 


The  equipment  which  has  been  installed  for  the  MILS  Project  consists  of  the  IBM  1800  system 
components,  instrument  interfaces,  laboratory  communication  control  boxes,  and  communica¬ 
tion  cable.  A  summary  of  this  equipment  is  presented  in  this  section.  The  computer  room  is 
diagrammed  in  Figure  2. 


1800  COMPONENTS 

1802 

CPU 

1828/1851 

Enclosure  with  Analog  Input  Features 

1826 

Enclosure  with  Digital  Input/ Output  and  Printer  Selector  Channel 

1826 

Enclosure  with  Selector  Channel  for  2311  and  1231 

1826 

Enclosure  with  1816  Print  Expanders 

1810 

Disk  Storage;  Program  Residence 

2401  (2) 

Tape  Drives:  9  Track  800  BPI 

2311 

Disk  Storage;  Hospital  Information  Base 

2841 

Storage  Control 

282’ 

Control  Unit 

1403 

Line  Printer 

1416 

Train  Cartridge 

1442 

Card/ Read  Punch 

1816  (5) 

Printer  Keyboards 

1053 

Label  Printer 

1231 

Optical  Mark  Page  Reader 

1316  (3) 

Disk  Storage  Packs 

029 

Keypunch 

1826 

Enclosure  with  T/P  Communication  Adapters  (5) 

1896  (5) 

Line  Adapters  (Modems) 

2740/2760  (7) 

Ward  Terminals 

3.2  ONLINE  INSTRUMENTATION 

The  online  instrumentation  consists  of  instrument  interfaces  which  enable  acquisition  of  instru¬ 
ment  signals,  control  boxes  for  operator  communication  and  direct  data  entry  devices.  The 
online  devices  are  listed  below.  Figure  3  illustrates  the  placement  by  laboratory  section. 


a.  SMA 

b.  SMA  Control  Box 

c.  General  AA  Control  Box 

d.  A. A.  Hi 

c.  A. A.  #1  Control  Box 

f.  A. A.  #2 

g.  A.A.  #2  Control  Box 

h.  A.A.  #3 

i.  A.A.  /(3  Control  Box 

j.  A.A.  H 

k.  A.A.  H  Control  Box 
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1802 

1826 

1826 

1826 

1826 

T/P 

Analog 

CPU 

Digital  I/O 

Keyboard 

Selector 

Input 

Adapters 

Channels 

mcations 

1816 
Opera  lor 
Console 


1810 

Program 

Residence 


1442 

Card 

Read/Punch 


2401(2) 


History 

Files 


1403 

Line 

Primer 


2311 
Hospital 
Data  Base 


2821 

Control 

Unit 


2841 

Control 

Unit 


Figure  2.  Computer  Room  Layout 


LAB  RECEPTION  AREA 


1231 

1816 

1816 

1053 

Optical  Page 

A&D 

Test 

Label 

Redder 

Rett 

Printer 

HEMATOLOGY  ONLINE  INSTRUMENTATION 


1816 

Ldb 

Commit* 

medium 

Coulter  ‘S' 

1 

Oiff. 

Counter 

1 

Fibrom- 

eter 

STAT  LAB 


OkjiUI 

Result 

Entry 


CHEMISTRY 


1810 

L.il) 

Commit- 

titration 


SMA 

12 


A  A 

cl/co2 


A  A. 

BUN/GLU 


A. A. 

Creatinine 


A. A. 
Spate 


Flame 

Photomctei 

NA/K 


SPECIAL  CHEMISTRY 


Spi'CtiO- 
pholof  luo- 
i  omelet 


Figure  15.  Laboratory  Equipment 
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l.  I.L.  Flame 

m.  I.L.  Flame  Control  Box 

n.  Aminco- Bowman 

o.  Aminco-Bowman  Control  Box 

p.  STAT  Control  Box 

q.  Fibrometer 

r.  Fibrometer  Control  Box 

s.  Differential  Counter 

t.  Coulter  "S" 

u.  Coulter  "S"  Control  Box. 


3.3  WARD  TERMINALS 

The  2740/2760  terminals  have  been  installed  for  ward  communications  in  the  following 
William  Beaumont  General  Hospital  locations: 

a.  Ward  7  (Surgical  ICU) 

b.  Ward  10  (OB/ GYN) 

c.  Ward  22  (Medicine) 

d.  Ward  23  (Medicine) 

e.  Ward  26  (Medicine  ICU) 

f.  Ward  28  (Medicine) 

g.  Computer  Room. 

A  terminal  has  been  retained  in  the  computer  room  for  use  in  training,  for  demonstrations 
and  for  use  in  additional  developments. 


14 


Section  4. 


SOFTWARE 


4.1  REALTIME  CONCEPTS 

In  realtime  processing,  the  reactive  software  must  meet  response  criteria  imposed  by  the 
many  devices  capable  of  delivering  inputs.  These  devices  may  be  operational  individually  or 
simultaneously.  The  software  must  incorporate  realtime  concepts  to  support  the  asynchronous 
arrival  of  data  and  the  unscheduled  input  from  multiple  users.  The  success  of  this  operation 
revolves  around  detection  and  servicing  of  interrupts.  Programs  which  receive  immediate 
control  when  an  interrupt  occurs  are  constructed  to  execute  as  fast  as  possible.  Their  func¬ 
tion  is  to  analyze  the  interrupt  and  determine  the  course  of  action  to  be  taken.  Requirements 
for  additional  processing,  resulting  from  each  interrupt,  are  serviced  by  logging  an  entry 
(queue)  for  the  appropriate  action  program.  Control  will  be  passed  to  the  action  program 
depending  on  system  activity  and  the  relative  priority  of  this  program.  Meanwhile,  the  interrupt 
handler  has  been  free  to  respond  to  a  subsequent  interrupt,  having  used  only  an  infinitesimal 
time  segment. 

The  Multiprogramming  Executive  (MPX)  operating  system  was  selected  for  MILS  because  it 
provides  the  features  essential  for  the  high  system  usage  requirements  of  the  computerized 
clinical  laboratory.  Multiprogramming  is  the  concept  which  permits  more  than  one  task  to  be 
in  operation  at  the  same  time.  The  core  storage  available  for  program  execution  is  segmented 
into  partitions.  The  MILS  System  has  been  configured  to  use  five  partitioned  areas  for  multi¬ 
programming  with  additional  time-sharing  of  batch  jobs  in  area  5  (VCORE).  This  has  the  effect 
of  making  one  central  computer  look  like  five  small  ones  operating  under  control  of  the  Exeu- 
tive  (see  Figure  4).  All  five  may  be  active  at  any  given  time,  using  the  CPU  when  control  is 
passed  to  it.  Contention  between  partitions  is  resolved  oi  a  priority  basis.  A  further  priority 
level  is  used  for  multiple  functions  within  a  partition.  A  program  in  operation  may  be  sus¬ 
pended  due  to  a  higher  priority  demand  for  execution.  On  completion  of  the  higher  priority 
work  the  interrupted  task  is  resumed  at  the  point  of  interruption.  Similarly  a  task  may  be 
suspended  while  performing  I/O  operations.  Another  task,  even  a  lower  priority  one,  may  be 
given  control  while  the  I/O  operation  is  in  process.  Optimum  use  of  the  execution  power  is 
made  since  available  work  is  being  performed  while  data  is  being  transferred  to  and  from  the 
relatively  slow  I/O  devices.  Maximum  overlap  of  I/O  with  computing  is  attained. 

MPX  control  provides  the  disk  management  necessary  for  maintaining  a  library  of  programs 
used  in  the  system.  It  handles  the  cataloging  when  programs  are  added,  deleted  or  changed. 
Programs  are  placed  in  the  file  in  executable  form  so  the  dynamic  allocation  in  response  to 
realtime  requests  is  handled  efficiently.  The  use  of  MPX  provides  the  high  throughput  and 
fast  response  essential  in  support  of  the  online  functions.  The  efficient  use  of  processor  time 
in  execution  scheduling  enhances  the  system  response  to  user  needs.  The  disk  management 
features  eliminate  potential  program  handling  and  storage  problems.  The  time  sharing  of 
batch  jobs  makes  the  power  of  the  computer  available  for  further  tasks  even  when  the  labora¬ 
tory  system  is  in  an  operational  status, 


4.2  PROGRAM  SUMMARY 

To  accomplish  the  total  MILS  development,  programs  were  written  in  these  categories: 


Permanently  Resident 


MPX 

Interrupt  Service 
MILS  I/O 


700 

Data  Acquisition 

II 

Data  Analysis 

1100 

III 

Test  Requisition 

Label  Generation 

Collection 

2000 

Offline  Results 

IV 

A  &  D 

1800 

Lab  Communication 

V  Utility 


Lei)  Reports 
Patient  Reports 

5100  File  Maintenance 


Figure  4.  Core  Memory 


a.  General  system  utility  programs 

b.  Data  base  management 
e„  Ward  communications 

d.  Admission  and  discharge 

e.  Test  requisition  processing 

f.  Laboratory  data  acquisition 

g.  Reports. 

The  individual  programs  in  each  category  are  listed  in  the  following  summary.  A  brief 
description  of  the  function  of  each  is  included. 


4.2.1  General  System  and  Utility  Programs 
a.  Program  Utilities 


1. 

AB53 

Convert  binary  to  1053  code  (four  digits) 

2. 

DB43 

Convert  4-digit  number  to  1443  code 

3. 

KSORT  - 

Numeric  sort  subroutine 

4. 

MB43  - 

Convert  binary  to  1443  code  (five  digits)  and  suppress 
leading  zeros 

5. 

MBRT1  - 

Print  MILS  error  messages.  Core  loads: 

MBRT1  -  Partition  H 
MBRT2  -  Partition  #2 
MBRT3  -  Partition  II 3 
MBRT4  -  Partition  #4 
MBRTV  -  VC  ORE 


6.  RBPDS 

7.  RCVTS 

8.  RDMSS 

9.  RP53S 
10.  RPDBS 


Binary  to  packed  decimal  conversion  (four  digits) 
Binary  to  1443  (ten  digits)  suppressing  leading  zeros 
Multiply  double  word  by  single  word 
Packed  decimal  to  1053  conversion  (four  digits) 
Packed  decimal  to  binary  conversion  (four  digits). 


b.  Operator  Utilities 


1. 

A  BOM  - 

Open  MILS  files  under  BOM 

2. 

ALIN  - 

Align  printer  for  reports 

3. 

ALST  - 

Card-to-print  (80/80) 

4. 

CECLZ  - 

C.E,  coreload  -  print  device  errors 

5. 

CHECK  - 

Test  for  analog  overload 

8. 

DIAG 

Digital  input/output  diagnostic 

7. 

DONOF  - 

System  1816  Online/Offline  Message  Printer 

8. 

KRLD  - 

2311  dump/reload  to/from  tape 

9. 

KTDMP  - 

Tape  dump  routine 

10. 

OLDMP  - 

Modified  system  program  to  use  PRNTN  for  output 

11. 

PUNCH  - 

Duplicate/ resequence  cards 

12. 

RCiPC  - 

Console/Interrupt  core  dump 

13. 

STAR  - 

Lab  terminal  online/offline  message  control 

14. 

TKOPY  - 

Tape  copy  routine 

15. 

UCS 

Stand-alone  load  UCS  buffer  for  1403. 
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c.  Cold  Start 


If 


1.  ACPEN  -  i 

2.  COLDS  - 

3.  DVOLT  - 

4.  JKDWS  - 

5.  KDATE  - 

6.  KEYBI  - 

7.  KIN 

8.  KPROT  - 

d.  Device  Support: 


Open  MILS  files  (at  cold  start) 

Cold  start  teleprocessing  initialization 

Read  power  supply  voltages 

Day  of  the  week  computation 

Date  initialization  in  common 

Keyboard  initialization  at  cold  start 

Cold  start  control  program 

Protect  MILS  resident  code  at  cold  start. 


1.  1231 


K1231  -  1231  interface  logic 

KTOCR  -  1231  interface  logic 
KLMSE  -  Error  coreload  for  1231 
KLSLM  -  1231  control  coroload 


2.  1816 


KYBD1  -  Keyboard  interface  subroutines.  Entry  points: 

KYBDl  -  A&D  keyboard 
KYBD2  -  Reception  area  keyboard 
KYBD3  -  Chemistry  section  keyboard 
ICYBD4  -  Hematology  section  keyboard 
KYBD5  -  Computer  room  keyboard 


3.  1403 


CUCSS  -  Load  UCS  buffer  for  1403. 


4.2.2  Data  Base  Programs 


a.  Operator  Utilities 


1.  ADAC 

2.  ADSB 

3.  ADMP 

4.  ATSD 

5.  BOMC 

6.  DLL12 

7.  KBLST 

8.  KDBUG 

9.  KLF 
10.  TESTF 


Dump  ACPAT  file  (indicators,  etc.) 

Dump  MILS  files  data  set  buffers  (from  disk) 

Dump  MILS  files  lock  list,  data  set  buffers  (from  core) 
Dump  specified  TESTS  file  records 
Dump  total  Inpatient  file 
Load  list  file  initializer 

Zero  test  file  counts  and  inpatient  chain  pointers 
Dump  inpatient  data 
Initialize  collection  schedule  file 
Check  TESTS  file  record  allocation. 


b.  Access  Routines: 


1.  AFNDK  -  Find  a  given  TESTS  file  entry,  selective  write.  Entry  points: 
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2.  AFNDT  - 


3.  ARPTK  - 

4.  DSKIO  - 


5.  KMRD  - 

6.  KMWRT  - 

7.  RAPXS  - 

c.  Applications: 


1. 

ABL1 

- 

2. 

ABL2 

- 

3. 

ANIT1 

- 

4. 

KMFJ0J0 

- 

5. 

KMF01 

- 

6, 

KMFJ02 

- 

7. 

KMF03 

- 

8. 

KMF04 

- 

9. 

KMFJ05 

- 

10. 

KMF11 

- 

11. 

KMF12 

- 

12. 

KMF13 

- 

13. 

KM  FI  5 

- 

14. 

KMF17 

- 

15. 

KMF30 

- 

16. 

KMF33 

- 

17. 

KMF35 

- 

18. 

KMF37 

- 

19. 

KMISC 

- 

20. 

KNAME 

- 

21. 

KPQCM 

- 

22. 

MUSTC 

- 

AFNDK  -  Search  for  accession 
APUTK  -  Update  the  record 
AFNUK  -  Unlock  the  record 

Search  TESTS  file  and  update  for  a  given  test  ^/accession  #.  Entry 
points: 

AFNDT  -  Search 
APUTT  -  Update 

Compute  the  number  of  physical  records  per  track  for  a  2311  data 
set 

Perform  disk  I/O  functions  for  MILS  files.  Entry  points: 

DSKIO  -  Read,  write,  or  lock  a  record 
UNLOC  -  Unlock  a  record 
ACLOS  -  Close  the  MILS  files 

Read  a  miscellaneous  file  table 
Write  a  miscellaneous  file  table 
Get  active  patient  record  number. 


Read  test  descriptor  cards  and  store  them  on  disk 

Process  test  descriptor  cards,  update  TESTA,  TESTB,  TESTS  file 

Initialize  MILS  files  (format  them,  update  data  set  buffers) 

Start  file  maintenance 
Tie  up  Area  1  for  file  maintenance 
Tie  up  Area  2  for  file  maintenance 
Tie  up  Area  3  for  file  maintenance 
Tie  up  Area  4  for  file  maintenance 
Produce  file  usage  report 
Inpatient  history  file  chain  updates 
Make  active  patient  file  list 
Rechain  and  pack  active  patient  file 
Pack  test  file 

Save  outpatient  history  file 

Make  list  for  inpatient  file  and  inpatient  history  file  deletions 

Save  inpatient  history  file  deletions 

Pack  inpatient  history  file 

Pack  inpatient  file 

Create  miscellaneous  file  control 

Initialize  standard  and  control  names  in  the  active  patient  index 
file 

Initialize  quality  control  file  records 
Update/initialize  STATS  file. 
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4.2.3  Ward  Communications 


a.  General  Purpose  Routines 


1.  CBLSS 

2.  CTIPS 

3.  CTPEC 

4.  CTPMS 

5.  CTPUC 
C.  M53LS 

7.  MBUFS 

8.  MENDS 

9.  MLIN0 


Activate  non-transaction  unbuffering 
Teleprocessing  interface  subroutine 
Teleprocessing  error  processing 
Teleprocessing  online/offline  messages 
Teleprocessing  restart  terminal/line 

Convert  a  string  of  1053  characters  to  line  compatible  code 
(for  T/P  lines) 

Buffer  one  line  of  data  (destined  for  a  2740  terminal)  to  dish 
Type  a  standard  end  message  on  a  2740  terminal 
Supervise  the  buffering  of  T/P  output.  Entry  points: 


MLINJ0 

MLIN1 

MLIN2 

MLIN3 


Initialize  a  line  buffer 
Provide  2740  spacing 
Buffer  a  string  of  data 
Close  the  line  buffer 


10. 

MPIDS 

Type  a  report  heading  and  patient  identification  (name,  SS#, 
ward,  bed)  for  a  given  patient 

11. 

MPNTS 

*“ 

Determine  address  of  terminal  device  table  for  a  specified 

T/P  terminal 

12. 

MUNBC 

Unbuffer  T/P  data  for  all  T/P  lines  (read  data  from  disk,  start 
the  typing) 

13. 

MWRTS 

Unpack  and  convert  a  string  of  data  and  send  it  to  a  given  T/P 
terminal 

14. 

RENDS 

- 

Print  asterisks  and  line  feed 

15. 

ROUTC 

- 

T/P  2760  to  action  core  load  interface. 

Applications 

1. 

CHWBC 

- 

Change  ward/bed  via  2760 

2. 

CREQC 

- 

Test  request  via  2760  -  error  checking 

3. 

CROSC 

- 

Ward  roster  on  2740 

4. 

CRQCC 

- 

Test  request  via  2760  -  create  active  patient  record 

5. 

CRQDC 

- 

Test  request  via  2760  -  aid  to  patient  chain 

6. 

MHS1C 

Preprocess  a  list  of  selected  tests  and  pass  control  to  MHS2C 
(T/P  -  history  results) 

7. 

MHS2C 

Build  a  table  of  history  results  for  one  test  for  one  patient 
(T/P  -  history  results) 

8. 

MHS3C 

*■* 

Process  a  table  of  history  results,  format  and  type  them 
(T/P  -  history  results) 

9. 

MTD1C 

- 

Current  results  driver  1 

10. 

MTD2C 

- 

Current  results  driver  2 

11. 

MTD1S 

Process  ACPAT  string  for  a  given  patient,  build  temporary 
report  records  (T/P  -  STAT/ current  results) 

12. 

MTD2S 

Process  report  records,  format,  and  type  current  results  for  a 
given  patient  (T/P  -  i> TAT/ current  results) 

13. 

RST1C 

- 

STAT  results  temporary  file  data  builder 

14. 

RST2C 

- 

STAT  results  printer 

15. 

RSTAC 

- 

Report  STAT  results  on  2740  master. 
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4.2.4  Admission  and  Discharge 
a.  Applications 

1.  CAD1C  -  Update  collection  schedule  file  via  A&D  functions 

2.  CAD2C  -  Update  patient  identification  data  via  A&D  functions 

3.  KAND  -  Admission  and  discharge  control 

4.  KANDE  -  Restart  coreload  for  KAND. 


4.2.5  Requisition  Processing 


a.  Test  Requisition 


1.  CAP3C 

2.  CSCHC 

3.  CUPCC 

4.  CUPCS 

5.  KLIR 
G.  KLPRE 

7.  KOPR0 

8.  KOPRO 

b.  Labels 

1.  KLAB4 

2.  KLAB5 

3.  KLABG 

4.  KLABG 

5.  KLRDB 
G.  KLRDL 

c.  Collection 


Area  three  keyword  analjzer 

Collection  file  updates  for  1231  inputs 

1231  file  update  control  -  patient  files 

File  updates  subroutine  -  patient  files 

Inpatient  test  request  control  logic  (through  1231) 

Error  coreload  for  non-collection  test  requests 
Outpatient  test  request  -  operator  communication 
Outpatient  test  request  -  error  checking  and  code  conversion. 


Test  request  -  assign  a. - sion  numbers  (not  ward  rounds) 

Test  request  -  create  active  patient  record  and  test  file  records 
(not  ward  rounds) 

Test  request  -  print  label  (not  ward  rounds) 

Test  l'equest  -  exception  processing  (not  ward  rounds) 

Redo  a  label  -  print  label 

Redo  a  label  -  locate  and  initialize  for  printing. 


1.  CSCHS  -  Collection  schedule  file  updates.  Entry  points: 

CSCI1S  -  Update  ward/bed  entry 

CSC1I1  -  Set  collection  required  indication 

CSCH2  -  Add  inpatient  record 

CSCH3  -  Modify  or  delete  inp  .'lent  records 


2.  KLCL 

3.  KLCL1 

4.  KLCLE 

5.  KI.PIR 
G.  KLVER 


Start  collection  schedule 

Generate  collection  schedule 

Restart  coreload  for  KLCL 

Audit  trail  for  collection  schedule  generation 

Verify  ward  rounds. 


•t.2.G  Data  Acquisition 

a.  Instrumentation  Controls 

1.  AGAAl  -  General  AutoAnalyzer  Control  Box  functions  -  beginning  sample, 
delete,  dilute,  stop 
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2.  AGAA2  -  General  AutoAnalyzer  Control  Box  function  -  last  valid  sample 

3.  AGAA3  -  General  AutoAnalyzer  Control  Box  function  -  add 

4.  AGAAC  -  General  AutoAnalyzer  Control  Box  master 

5.  ASMAl  -  SMA  Control  Box  functions  -  beginning  sample,  delete,  dilute,  stop 

6.  ASMA2  -  SMA  Control  Box  function  -  last  valid  sample 

7.  ASMA3  -  SMA  Control  Box  function  -  add 

8.  ASMAC  -  SMA  Control  box  master 

9.  ATINP  -  Turn  in  Progress  Bit  On/ Off  in  TESTS  for  a  given  accession  #  and 

test 

10.  D1B00  -  Coulter  Counter  'S'  data  acquisition 

11.  D1B01  -  Individual  Analyzer  Control  Box  interrupt  processing.  Entry  points: 

D1B01,  D1B04,  D1B07,  D1B10  -  Start  functions 
D1B02,  D1B05,  D1B08,  D1B11  -  Stop  functions 
D1B03,  D1B06,  D1B09,  D1B12  -  Zero  transmittance 

12.  D1B13  -  SMA  start/stop  interrupt  processing.  Entry  points: 

D1B13  -  Start 
D1B14  -  Stop 

13.  D1B15  •  SMA  channel  change  interrupt  processing 

14.  D2B00  -  Coulter  'S'  sequence  change  interrupt  processing 

15.  D2B01  -  Light  x’ecognize  interrupt  processing.  Entry  points: 

D2B01  -  Coulter'S' 

D2B03  -  General  AutoAnalyzer 

D2B09  -  SMA 

D2B04  -  A. A.  Ill 

D2B05  -  A. A.  if 2 

D2B06  -  A. A.  if 3 

D2B07  -  A. A.  if  4 

D2B12  -  Fibrometer 

03 B02  -  Aminco- Bowman 

D3B05  -  I.L.  Flame 

D3B08  -  STAT  Box 

D3B10  -  Differential  Counter 

1G.  D2B02  -  Control  Box  message  transmit  interrupt  processing.  Entry  points: 

D2B02  -  General  AutoAnalyzer 
D2B08  -  SMA 

17.  D2B10  -  SMA  specimen  change  interrupt  processing 

18.  D2B11  -  BBL  interrupt  processing.  Entry  points: 

D2B11  -  Message  transmit 
D2B13  -  BBL  start 
D2B14  -  BBL  stop 
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19.  D3B00  -  Control  Box  interrupt  processing.  Entry  points: 

D3B00  -  Aminco- Bowman  read 

D3B01  -  Aminco- Bowman  message  transmit 

D3B03  -  I.L.  Flame  read 

D3B04  -  I.L.  Flame  message  transmit 

D3B06  -  STAT  Box  read 

D3B07  -  STAT  Box  message  transmit 

D3B09  -  Differential  Counter  message  transmit 

20.  DDAOP  -  Digital  output  control  routine 

21.  DGAAl  -  Activate  instrument  monitoring.  Entry  points: 

DGAAl  -  A.A.  #1 
DGAA2  -  A.A.  #2 
DGAA3  -  A.A.  #3 
DGAA4  -  A.A.  H 
DGAA5  -  A.A.  #5 

Terminate  instrument  monitoring.  Entry  points: 

DGADl  -  A.A.  Ill 
DGAD2  -  A.A.  #2 
DGAD3  -  A.A.  113 
DGAD4  -  A.A.  #4 
DGAD5  -  A.A.  II 5 


1).  Online  Data  Acquisition 


1 .  DAAPK 

2.  DA  ARP 

3.  DCCSC 

4.  DEMSP 

5.  DSCAN 
0.  DSMAO 


AutoAnalyzer  peak  picker 
AutoAnalyzer  peak  wrap-up 
Coulter  'S'  results  wrap-up 
AutoAnalyzer  error  messages 
AutoAnalyzer  analog  read 

Activate/deactivate  SMA  data  collection.  Entry  points: 


DSMAO  -  Activate 
DSOFF  -  Deactivate 


7.  DSMAS  -  SMA  analog  read 

8.  RABSC  -  Am  in  co -Bowman  wrap-up 

9.  RBBLC  -  BBL  wrap-up 

10.  RCd'2C  -  STAT  Entry  Box  wrap-up 

11.  RDCMC  -  Differential  count/morphoiugy  wrap-up 

12.  RESUL  -  Compute  results  of  load  list 

13.  RILFC  -  I.L.  Flame  wrap-up 

14.  RUTAS  -  Update  files  for  non-load  list  instrumentation 

15.  SWRAC  -  Move  SMA  data  to  fi7e. 


c.  Offline  Data  Acquisition 

1.  DCOMP  -  Results/time  of  urine  tests 

2.  KLO02  -  Offline  results  2,  3,  4  digits 
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3. 

KLO.04 

4. 

KLO06 

5. 

KLO08 

6. 

KLO10 

7. 

KL012 

8. 

KL014 

9. 

KL016 

10. 

KL018 

11. 

KLO20 

12. 

KL022 

13. 

KLOMl 

14. 

KLOM2 

15. 

KLOM3 

16. 

KLOM4 

17. 

KLOM6 

18. 

KLORU 

19. 

KLORV 

Offline  results  choice  of  2  items 

Offline  results  choice  of  3  items 

Offline  results  choice  of  4  items 

Offline  results  choice  of  more  than  4  items 

Offline  results  miscellaneous  quantitative  with  control 

Offline  results  body  fluid  counts 

Offline  results  semen  analysis 

Offline  results  routine  urinalysis 

Offline  results  urobilinogen  or  mucopolysaccharides 

Offline  results  differential  count  and  morphology 

Offline  results  PTDF 

Offline  results  blood  gases 

Offline  results  gastric  analysis 

Offline  results  2,  3,  4  digits  with  control 

Offline  results  2,  3,  4  digits  with  control  -  PT 

Update  files  for  offline  results 

Update  files  for  offline  results  (differential  count  and  morphology). 


d.  List  Pi’eparation 


1. 

DADDC 

2. 

DADDO 

3. 

DADMC 

4. 

DAUTC 

5. 

DCAP1 

6. 

DLCK3 

7. 

DLCK5 

8. 

DLLAT 

9. 

DLLC1 

10. 

DLLR# 

11. 

DLLRD 

12. 

DPLLC 

13. 

LLPRT 

"ADD"  keyword  master 

Add  one  specimen  to  a  load  list 

Add  all  available  to  a  load  list 

Audit  trail  AutoAnalyzer/SMA  activity 

Laboratory  communication  keyword  control 

Load  list  master  control 

Work  list  report 

Load  list  build  audit  trail 

Load  list  builder 

Find  a  load  list  entry  using  record  number 
Find  a  load  list  entry  from  scratch 
Reprint  load  list  master  control 
Print  a  load  list. 


e.  Print  Results 


1.  DLCK4 

2.  DRSC1 

3.  DRSC2 

4.  DRSC3 

5.  DRSC4 

6.  DRSCM 


Lab  results  master  control 
CBC  load  list  results 
SMA  load  list  results 
Single  channel  load  list  results 
Two  channei  load  list  results 
Print  mark  sense/SCI  results. 


f.  Work  Lead  Status 


1.  DLCK1  -  Work  load  leport. 


g.  Verify  Results 


1.  DLCK6 

2.  DLVAT 

3.  DVLRC 

4.  DVLRL 

5.  RVIPS 


Verify  lab  results  master  control 
Verify  load  list  audit  trail 
Modify  a  load  list  result  (VLR) 
Verify  a  load  list 
Set/ reset  verify  in  process  bit. 
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h.  Specimen  Condition  Data 

1.  DSCIC  -  Specimen  Condition  Information  (SCI)  master  control 

2.  DSCn  -  Post  "SCI"  condition  in  file. 


4.2.7  Reports 

a.  Laboratory  Management 

1.  Section  Reports 

(a)  ADLOG  -  Process  INHST,  OPHST  files,  print  daily  log 

(b)  DACC#  -  Specimen  retention  report 

2.  Quality  Control 

(a)  GQCC  -  Quality  control  master  program 

(b)  GQCFM  -  Quality  control  data  collection 

(c)  GQCP  -  Quality  control  report  master  program 

(d)  QCCPR  -  Quality  control  computation 

(e)  QCREP  -  Offline  quality  control 

(f)  QCRPT  -  Quality  control  format  and  print. 

3.  Statistics 

(a)  CSTAC  -  Statistics-demand  reports 

(b)  MDSTC  -  Process  TESTS  file,  update  STATS  file,  print  daily 

statistics  report 

(c)  RLLSS  -  Load  list  standard/QC  counter. 

b.  Inpatients 

1.  Cumulative 

(a)  ACPR1  -  Scan  ACPAT  file,  update  INHST  file 

(b)  ACPR2  -  Sort  inpatient  history  index  file  by  ward/bed 

(c)  ACPR3  -  Process  INHST  file,  print  cumulative  reports. 

2.  Midday 

(a)  AIPR0  -  Initialize  VCORE  COMMON  for  midday  inpatient  reports 

(b)  AIPR1  -  Process  ACPAT  file,  select  inpatients,  build  and  sort  temporary 

index  file  for  midday  patient  reports 

(c)  AIPR2  -  Build  temporary  report  record  for  one  patient 

(d)  AIPR3  -  Process  report  record,  print  midday  report  for  one  patient. 

3.  Admission  Status 

(a)  BINPT  -  Alphabetic  dump  of  inpatient  file. 
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c. 


Outpatients 
1  .  Daily 


(a)  A0PR1 

(b)  AOPR2 

(c)  AOPR3 


Scan  ACPAT  file,  build  OPHST  file 

Sox't  outpatient  history  index  file  by  clinic/doctor 

Process  OPHST  file,  print  outpatient  reports. 


d.  Report  Utilities 


1.  ANSWR 

2.  APATR 

3.  APRNT 

4.  ARERR 

5.  ARRET 


Convert  a  packed  decimal  number  to  1443  code,  insert  decimal  point, 
and  suppress  leading  zeros 

Select  inpatient/outpatient  reports  for  execution  (based  upon  key¬ 
board  input) 

Print  a  line  and  allow  overlapped  processing 

Type  an  error  message  (for  patient  reports)  and  abort 

Type  an  error  message  (for  patient  reports)  and  return. 


4.3  FILE  SUMMARY 

The  seventeen  files  listed  below  are  contained  in  the  MILS  data  base.  The  information  is 
organized  to  meet  a  variety  of  access  and  retrieval  requirements.  Variations  in  indexing  and 
sequencing  have  been  established  to  minimize  file  sorting  and  to  be  responsive  to  demands 
from  laboratory,  admissions  and  hospital  wards. 

a.  Inpatient  File— This  file  contains  the  name,  social  security  number  and  other 
identifying  information  for  each  inpatient.  The  data  is  entered  when  a  patient  is 
admitted  and  is  purged  when  the  patient  is  discharged. 

b.  Active  Patient  File— This  file  contains  data  for  those  inpatients  and  outpatients  lor 
whom  laboratory  work  has  been  requested.  The  data  for  each  patient  consists 
basically  of  indicators  (i.e.,  test  complete,  specimen  not  collected,  etc.)  for  the 
various  tests  that  have  been  requested. 

c.  Active  Patient  Index  File— This  file  is  organized  by  accession  number.  Each  entry 
points  to  the  data  in  the  Active  Patient  File  for  a  given  accession  number. 

d.  Collection  Schedule  File— This  file  consists  of  one  or  more  records  for  each 
hospital  ward.  Each  record  contains  indicators  as  to  whether  specimens  are  to  be 
drawn  during  ward  round  collection.  For  each  bed  assigned  to  a  ward  there  is  a 
pointer  to  the  assigned  patient's  Inpatient  File  record. 

e.  Test  File— This  file  is  organized  by  test  number  and  contains  the  status  and  results 
of  all  online  and  offline  tests  that  have  been  requested  for  the  patients  whose  names 
are  contained  in  the  Active  Patient  File. 

f.  Load  List/Intermediate  Results  File— This  file  consists  of  load  lists  (i.e,,  list  of 
accession  numbers  and  related  cup  positions,  etc.)  for  the  various  online  instru¬ 
ments,  and  it  contains  the  results  of  the  online  tests.  The  laboratory  technician 
uses  the  data  in  this  file  to  set-up  his  load  list  and  to  run  his  instrument,  lie  then 
can  obtain  from  this  file  the  results  for  his  instrument  and  either  accept  or  modify 
the  results  (which  will  then  be  placed  in  the  test  file). 

g.  Inpatient  History  File— This  file  contains  the  results  of  all  laboratory  work  per¬ 
formed  during  each  patient's  stay  in  the  hospital. 

h.  Inpatient  History  Index  File— This  file  is  organized  by  Ward/Bed  and  points  to  data 
in  the  Inpatient  History  File. 
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i.  Outpatient  History  File— This  file  contains  the  results  of  all  outpatient  laboratory 
work  performed  during  the  current  day. 

j.  Statistics  File— This  file  contains,  for  each  unique  test/procedure  combination, 
counts  of  the  numbers  of  requests  and,  by  month,  counts  of  the  number  of  comple¬ 
tions.  For  each  unique  procedure  a  count,  by  month,  of  the  total  number  of 
standards  and  conti'ols  processed  is  maintained. 

k.  Quality  Control  File— This  file  contains  statistical  data  by  which  the  performance 
of  various  online  instruments  can  be  measured.  It  contains  daily  quality  control 
specimen  readings  and  statistical  measurements  (mean,  standard  deviation,  etc.) 
by  which  the  readings  can  be  compared. 

l.  Test  Descriptor  Files— These  files  contain  the  many  parameters  associated  with 
each  of  the  laboratory  tests  (both  online  and  offline).  The  parameters  guide  the 
collection  of  test  samples,  the  testing  of  the  samples,  and  the  reporting  of  the  test 
results. 

m.  Miscellaneous  File— This  file  contains  various  tables  of  data  needed  by  the  MILS 
System  programs. 

n.  Work  File— 'This  file  provides  a  temporary  disk  work  area  for  various  MILS  System 
programs. 

o.  T/P  Message  Buffer  File— This  file  is  used  for  buffering  of  messages  that  are 
destined  for  any  of  the  2740  communications  terminals. 

p.  Checkpoint  File— This  file  is  used  to  save  certain  checkpoint  information  that  must 
be  restored  (in  core  memory)  at  cold  start  time. 

q.  Card  Image  File— This  file  is  used  for  the  temporary  storage  of  data  cards. 
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Section  5. 


DESIGN  CONCEPTS 


5.1  DATA  TRANSMISSION 

Eight  different  types  of  instrumentation  and  eleven  operator  control  boxes  have  been  config¬ 
ured  for  online  data  acquisition.  This  extensive  instrumentation  configuration  with  the  varia¬ 
tions  in  instrument  characteristics  means  several  types  of  data  transmission  need  to  be 
accommodated.  High  level  analog  signals,  low  level  analog  signals,  digital  input  voltage  signals 
and  digital  input  contact  signals  are  required  inputs  to  the  central  processor.  Multiple  process 
interrupt  lines  are  installed  to  provide  instantaneous  response  to  the  operator’s  desired 
actions.  Digital  output  signals  are  incorporated  to  provide  control  light  indications  of  system 
actions. 

A  special  digital  input  feature  allows  multiplexing  of  digital  inputs  from  several  sources  for 
transmission  over  the  same  lines.  Economy  in  cabling  is  realized  without  degradation  in 
response  times. 

To  handle  the  total  spectrum  of  laboratory  information  processing,  several  different  peripheral 
devices  are  required.  Data  transmissions  are  accomplished  through  direct  attachments  to  the 
central  processor,  as  well  as  through  use  of  overlapped  data  channel  operations.  Remote  com¬ 
munications  for  data  transmissions  to  and  from  ward  terminals  require  start/stop  telepro¬ 
cessing  techniques.  Thus,  common  telephone  cable  can  be  used  for  the  transmission  media. 


5.2  SYSTEM  OPERATIONS 

The  design  philosophy  which  has  been  followed  is  that  the  computer  system  should  be  an 
instrument  used  to  accommodate  the  exploding  information  handling  requirements.  The  sys¬ 
tem  does  not  remove  the  responsibility  for  judgments  regarding  the  integrity  of  laboratory 
results.  Design  concepts  allow  for  sy  stem  printouts  of  information  prepared  manually  or  by- 
instrument.  The  ability  to  make  changes  or  rerun  as  desired  is  an  option  available  to  the 
user  prior  to  his  verification  which  makes  results  available  for  reporting.  Out-of-limits 
warnings  are  provided  as  operator  alerts  only.  Acceptance  or  rejection  remains  an  operator 
responsiblity.  Hard  copy  is  provided  so  all  users  may  maintain  individual  records  of  their 
test  activity. 

System  checks  are  provided  for  users  where  their  action  can  update  the  information  base. 
Checks  are  built  in  which  require  a  positive  response  prior  to  taking  final  action. 

A  log  of  key  events  and  the  times  of  occurrence  is  printed  by  the  system  on  the  operator  con¬ 
sole,  This  provides  a  quick  look  status  of  instrumentation  or  communication  devices.  It 
further  provides  an  historical  record  of  system  usage  events. 

A  conversational  mode  of  communication  has  been  developed  for  users  of  keyboard  terminals. 
The  user  depresses  a  key  to  get  the  attention  of  the  computer.  The  computer  acknowledges 
and  the  operator  inputs  a  3-character  mnemonic  describing  the  function  he  wishes  to  perform. 
The  computer,  in  sequential  steps,  specifies  the  data  to  be  entered.  If  an  error  is  made  the 
field  is  not  accepted  and  the  user  is  notified  to  reenter.  A  positive  response  lets  the  user 
know  his  function  has  been  successfully  entered. 
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Design  considerations  for  the  optical  image  ward  terminal  inputs  permit  repeated  entry  of  the 
same  field.  The  last  entry  is  the  one  used  and  permits  immediate  overrides  for  mistakes.  In 
order  to  provide  operational  flexibility,  the  sequence  in  which  the  parameters  are  entered  is 
not  fixed.  Actions  which  can  modify  the  information  base  require  a  second  positive  response 
from  the  user.  Hard  copy  printouts  provide  the  location  records  for  actions  taken. 

The  system  is  designed  to  support  operations  on  a  demand- response  basis.  Request  for  out¬ 
puts  represent  status  at  that  moment.  Requests  and/or  directions  may  originate  at  any  term¬ 
inal  station  or  from  the  CPU  operator  console.  Interim  or  working  documents  (midday 
patient  reports,  for  example)  may  be  generated  at  any  time  and  as  frequently  as  desired.  The 
MILS  multiprogramming  system  provides  an  architecture  consisting  of  five  partitions,  ail 
of  which  may  have  operations  in  process  simultaneously.  Though  the  system  is  sequencing 
the  internal  operations  on  a  priority  basis,  the  appearance  to  the  user  is  that  the  system  is 
dedicated  to  his  request.  Further  timesharing  of  batch  type  processing  may  be  invoked  through 
the  operator  console. 

The  flexibility  of  the  MILS  design  does  not  dictate  that  a  fixed  set  of  procedures  be  performed 
in  a  specific  sequence.  The  system  can  be  utilized  in  the  manner  which  best  serves  the  needs 
of  the  installation.  The  procedures  being  used  at  William  Beaumont  General  Hospital  as  of 
May  1,  1972  had  the  system  in  operation  from  midnight  (0000)  to  eight  P.M.  (2000).  This 
schedule  was  being  followed  Monday  through  Friday.  The  system  was  also  in  operation 
Saturday  from  0730  -  1200.  The  schedule  guidelines  which  were  being  followed  by  operational 
personnel  are  shown  in  the  WBGII  SOP  (Attachment).  Events  need  not  take  place  at  the  specific 
times  noted.  Day  to  day  variations  in  work  loads  and  personnel  resources  cause  the  operational 
complexion  to  fluctuate. 


5.3  LABORATORY  SUPPORT 

Accession  numbers  are  assigned  by  the  system  for  all  requisitions  entered.  Numbers  are 
assigned  sequentially  from  0000  to  9999.  One  character  is  added  for  laboratory  section  identi¬ 
fication  -  H  for  hematology,  U  for  urinalysis,  etc.  Duplicate  accession  numbers  are  prevented 
if  some  are  still  active  when  numbers  are  recycled.  Accession  numbers  are  retained  in  an 
active  state  until  all  associated  work  is  complete.  The  design  is  structured  so  that  multiple 
requests  for  one  patient  may  be  combined  into  a  single  accession  number,  depending  on  the 
procedures  to  be  used.  Multiple  requests  which  cross  section  boundaries  receive  separate 
accessioning.  The  same  holds  true  if  different  type  of  specimen  are  involved.  Tests  which  are 
to  be  performed  in  the  same  section  can  be  singly  accessioned.  Volumes  of  specimen,  printed 
on  laboratory  labels,  receive  consideration  of  the  procedures  involved  and  the  minimum 
amount  is  specified.  Uncertainty  of  the  volume  required  for  multiple  requests  is  removed. 
Certain  tests  require  multiple  specimens  so  provision  is  made  for  separate  accession  number 
assignment  and  individual  label  preparation.  Some  examples  which  are  in  use  at  WBGH  are 
Oral  Glucose  Tolerance  (up  to  seven  blood  and  seven  urine  specimens),  Other  Glucose  Toler¬ 
ance  (Six  blood  specimens),  and  a  Hypertension  battery  (one  blood  specimen  and  one  urine 
specimen). 

Test  categories  are  established  for  adult,  infant,  and  child  age  groups.  Additional  categories 
are  established  to  distinguish  STAT  from  routine  requests.  All  test  attributes  are  defined  in 
the  system  for  each  category.  This  feature  permits  procedures  to  be  assigned  based  on  age 
group  and  type  of  request.  Volume  of  specimen  and  method  of  handling  multiple  requests  is 
structured  by  age  groups.  Normal  values  are  assigned  according  to  the  patient  category. 


Processing  of  each  acquisition  includes  the  assignment  to  an  online  procedure  or  a  manual 
method.  STAT  requests  can  be  assigned  procedures  different  from  the  same  test  appearing 
on  a  routine  request.  Different  procedures  may  be  assigned  depending  on  patient  age 
category. 

Test  batteries  are  defined  in  the  system  to  provide  grouping  of  individual  tests  for  diagnostic 
purposes  and  to  coincide  with  instrumentation  capabilities.  Requests  may  be  made  for  the 
battery,  or  individual  elements  in  the  battery  may  be  requested.  The  laboratory  may  specify 
which  elements  requested  individually  should  be  scheduled  as  an  instrumentation  battery  and 
which  should  be  scheduled  for  a  manual  procedure.  The  laboratory  has  the  facility  to  assign 
one  element  in  a  battery  to  the  automated  procedure  and  another  element  to  the  manual  pro¬ 
cedure.  For  example,  a  request  for  calcium  could  be  scheduled  for  performance  on  the  SMA 
while  a  request  for  total  bilirubin  could  be  scheduled  manually,  yet  both  are  elements  in  the 
SMA  battery.  Only  requested  elements  are  included  in  reports  returned  to  physicians. 

When  automating  the  information  handling  of  a  laboratory  section  it  is  necessary  that  all  tests 
performed  be  handled,  both  by  online  instruments  and  by  offline  instruments,  or  manual 
methods  be  supported  by  the  computer  system.  Partial  test  information  support  for  a  labora¬ 
tory  section  requires  dual  procedures  for  processing  requisitions,  maintaining  records  of 
test  status  and  results,  and  all  other  functions— negating  many  of  the  advantages  of  computer 
support.  Incorporating  all  tests  into  the  system  extends  the  scope  of  results  which  need  to 
be  entered  into  the  system.  Eleven  different  mark  sense  sheets  have  been  designed  to  handle 
the  entry  of  multiple  types  of  test  l’esults.  Thus  one  piece  of  equipment  is  sufficient  to  handle 
all  manual  test  result  entries.  Single  marks  on  the  sheet  are  translated  into  descriptive 
textual  results  on  physicians'  reports.  Numeric  answers  are  recorded  by  selecting  the 
appropriate  digit  from  0-9.  Text  answers  are  selected  from  the  list  preprinted  on  the  manual 
results  sheet.  All  tests  results  can  be  accommodated  using  combinations  of  these  mark  sense 
features. 

A  variety  of  methods  of  presenting  information  on  patient  reports  is  necessary  to  transmit 
all  results  to  the  requestor.  Numeric  results  or  tests  with  alpha  answers  with  less  than  five 
characters  can  be  presented  on  a  cumulative  report  horizontally  across  the  sheet.  Results 
with  text  results  or  text  data  intermixed  with  numeric  data  is  arranged  in  a  vertical  format 
sequenced  by  date. 


5.4  SYSTEM  MODIFICATION 

The  system  has  been  developed  recognizing  the  dynamic  nature  of  clinical  laboratory  services. 
The  frequency  of  change  in  tests  offered,  instrumentation  and  methods  dictates  the  need  for  the 
laboratory  information  system  to  be  responsive  to  this  changing  environment.  The  approach 
taken  was  to  establish  test  descriptor  and  procedure  files  within  the  data  base.  The  processing 
modules  reference  the  data  base  to  obtain  processing  directions.  These  files  contain  the  test 
attributes  (name,  abbreviation,  normals,  reporting  formats,  units,  specimen  volume,  etc.), 
procedure  assignments,  and  instrumentation  set-up  directions  (position  and  designation  of 
standards,  quality  controls,  blanks,  and  specimens).  Changes  in  laboratory  services  are 
recorded  on  punched  cards  and  processed  by  file  update  programs.  The  next  reference  to  the 
file  by  the  system  modules  residts  in  the  latest  version  of  the  descriptive  or  procedure  data 
being  used. 

Multiprogramming  techniques  have  been  selected  to  facilitate  software  changes  or  extensions. 
The  programs  which  have  been  written  were  modularized  to  execute  in  the  MPX  core  parti¬ 
tions.  Several  overlays  may  be  required  to  complete  a  logical  function,  but  this  concept  allows 
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additional  programs  to  be  added  within  lie  existing  hardware  configuration.  Changes  may  be 
made  in  the  program  library  while  the  system  is  online.  The  disk  management  program 
(DMP)  executes  in  the  background  to  replace  a  program  wiln  a  newer  version.  The  next  exe¬ 
cution  of  the  program  results  in  the  latest  version  being  used.  No  interruption  in  data  acquisi¬ 
tion,  inquiry  functions  or  other  activities  need  occur  while  this  system  modification  is  being 
performed. 


5.5  SYSTEM  RELIABILITY 

Fail  soft  techniques  have  been  incorporated  throughout  the  system  design  so  reduced  capa¬ 
bility  may  result  from  failure  of  individual  devices,  but  remaining  system  functions  continue. 
Only  three  devices  in  the  MILS  configuration  are  critical;  i.e.,  failure  in  any  one  of  these 
will  cause  the  system  to  be  inoperable  and  back-up  manual  methods  will  have  to  be  used  in 
the  laboratory.  The  critical  devices  are  the  CPU,  the  program  residence  file  and  the  hospital 
information  file. 

Laboratory  terminal  and  ward  terminal  design  has  been  incorpoiated  so  any  function  may  be 
performed  on  another  similar  device.  The  laboratory  label  printing  function  may  be  performed 
on  another  keyboard  should  the  label  printer  malfunction.  There  is  no  equipment  back-up  for 
the  line  printer  but  information  is  retained  on  the  file  for  printing  at  a  subsequent  time,  when 
repair  is  accomplished.  Meanwhile,  the  data  (such  as  test  starts  and  results)  is  available  for 
inquiiy  via  the  terminals.  A  failure  in  an  instrument,  its  interface  or  cable  results  in  loss  of 
online  data  acquisition  for  that  device  only.  Tests  which  have  been  scheduled  for  performance 
on  this  instrument  can  be  performed  manually  and  entered  using  the  offline  results  feature. 

Any  time  a  change  in  status  or  information  occurs  which  effects  subsequent  processing,  the 
status  is  checkpointed  on  system  files.  Should  the  system  be  taken  offline  for  some  period, 
the  latest  available  status  of  operations  will  be  reflected  uhen  online  support  is  restored. 
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Section  6, 


PROJECT  SUMMARY 


6.1  DEVELOPMENT 

The  Medical  Instrumentation  Linkage  System  (MILS)  has  been  developed  and  implemented  in 
an  environment  typical  of  the  large  U.S.  Army  hospitals.  The  laboratory  at  WBGH  is  repre¬ 
sentative  of  the  wide  variety  of  services  provided  and  of  the  size  of  the  patient  base  (inpatients 
and  outpatients)  requiring  the  services. 

Project  objectives  included  developing  the  system  and  placing  it  into  operation.  To  accomplish 
these  objectives,  several  transitions  in  the  mode  of  operation  were  necessary  during  the 
project  lifetime.  The  initial  period  was  dedicated  to  development  activities  pointing  toward 
the  first  major  operational  capability.  The  work  in  this  period  consisted  of  collecting  require¬ 
ments,  designing  the  system,  writing  the  programs  and  testing  the  so  bvv'  as  it  was  com¬ 
pleted.  The  computer  in  this  period  was  dedicated  to  the  development  anf{Mties.  When  develop¬ 
ment  and  test  were  completed  and  the  system  was  ready  for  operational  support,  a  transition 
was  made  to  a  parallel  mode  of  laboratoi’y  operation.  During  this  period,  laboratory  personnel 
retained  manual  operations  and  also  used  the  system.  No  dependence  was  placed  on  the  system 
nor  were  system  reports  transmitted  in  this  period.  This  period  provided  both  a  system  shake- 
down  and  training  of  user  personnel.  Program  discrepancies  not  detected  during  system  testing 
became  obvious  during  the  parallel  operation.  The  need  for  changes  in  initial  design  concepts 
also  became  obvious.  These  changes  affected  procedures,  programming  or  combinations  of  the 
two. 

The  transition  from  a  parallel  operation  to  a  dedicated  computer  operation  was  made  when 
sufficient  confidence  had  been  established  and  personnel  had  developed  a  sufficient  familiarity 
in  using  the  system.  At  this  point  developments  were  initiated  for  the  next  major  system  capa¬ 
bility.  The  development  effort  and  the  operational  use  diverged  at  this  point,  each  concen¬ 
trating  on  a  different  system.  Separate  periods  of  computer  use  needed  to  be  established  to 
support  both  objectives. 

The  operational  system  could  not  be  ignored  by  the  development  team.  Continuing  maintenance 
and  new  requirements  were  fulfilled  to  satisfactorily  support  the  continuing  operation.  'The 
effect  of  these  transitional  steps  was  that,  in  addition  to  completing  development,  operational 
experience  was  gained  as  a  capability  became  available.  Phasing  new  developments  into 
operational  use  meant  that  concepts  were  immediately  tried  under  "field  conditions."  Requests 
for  changes  and  additions  which  always  surfaced  as  soon  as  a  capability  was  put  into  actual 
use  were  accommodated.  Experience  has  shown  that  no  matter  how  lengthy  the  discussions 
preceding  the  writing  of  programs,  final  definition  of  requirements  occurred  only  after  a 
period  of  use.  A  realization  of  the  nature  of  new  developments  on  the  part  of  the  users  was 
necessary  for  continuation  of  progress.  Occurrence  of  program  bugs  or  discovery  of  initial 
limitations  had  to  be  accepted.  This  constructive  attitude  was  complemented  by  a  responsive¬ 
ness  in  making  the  program  changes  essential  to  successful  utilization.  Another  advantage  that 
accrued  from  the  continuing  implementation  steps  was  that  program  bugs,  detectable  only 
during  heavy  system  utilization  by  multiple  users,  were  found  and  corrected.  Certain  software 
bugs  are  so  subtle  that  the  combination  of  operational  events,  which  show  the  problem,  may 
not  occur  until  after  several  weeks  of  operational  use. 
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The  desire  to  implement  newly  developed  features  with  modifications  to  those  previously 
placed  in  operation  imposed  the  requirement  to  control  the  content  of  the  operational  system. 
The  operational  system  could  not  be  modified  to  include  features  which  were  incomplete  or 
which  have  not  been  thoroughly  tested.  The  integrity  of  operations  had  to  be  maintained  along 
with  continued  developments.  A  method  of  strict  Version  Control  was  put  into  practice  after 
the  laboratory  became  dependent  on  an  operational  system.  The  content  of  the  next  version 
to  be  released  for  laboratory  support  was  mutually  defined  by  programming  and  operations. 

A  date  would  be  selected  for  switchover  to  this  next  version  of  the  system.  A  memorandum 
would  be  published  prior  to  actual  release  in  which  all  changes  would  be  detailed,  including 
any  revisions  in  operational  procedures.  The  programming  staff  would  develop  and  test  the 
new  capabilities  o..  ^  test  system.  When  all  development  and  testing  was  satisfactorily  com¬ 
pleted,  the  test  system  would  be  copied  onto  the  operational  system.  The  previous  version  of 
the  operational  system  would  be  retained  for  a  couple  of  weeks  as  insurance  against  unantici¬ 
pated  failure  in  the  newly  released  system. 

The  programming  staff  participated  in  close  surveillance  for  the  first  few  days  following 
release  of  new  systems.  If  a  catastrophic  failure  should  have  occurred,  it  would  have  happened 
during  this  period  and  all  resources  could  have  been  applied  immediately  to  quickly  solve  the 
problem  and  minimize  the  impact  on  laboratory  operations. 

Any  time  a  problem  was  detected  in  the  software,  an  evaluation  was  made  to  determine  if  the 
fix  should  be  placed  on  the  operational  system  immediately  or  whether  the  problem  was  such 
that  the  fix  could  wait  until  release  of  the  next  version.  Those  fixes  which  could  be  postponed 
until  the  next  system  release  had  the  advantage  of  being  exposed  to  more  rigorous  testing. 
However,  certain  fixes  were  made  directly  to  the  operational  system  in  those  cases  where  the 
malfunction  was  causing  an  impact  on  routine  operations. 

The  maintenance  of  separate  test  and  operational  systems  meant  that  a  strict  accounting  of 
all  software  status  had  to  be  established  and  kept  current. 

The  separation  of  development  from  operations  meant  that  separate  periods  for  use  of  the 
1800  had  to  be  observed  by  the  two  groups.  The  1800  time-sharing  features  could  be  utilized 
for  limited  development  activities  during  operational  periods,  e.g.,  the  system  could  be  used 
to  perform  program  compilations  and  assemblies  and  utility'  functions  in  the  background, 
while  the  laboratory  was  online.  Execution  of  programs  in  a  development  state  could  not  b.' 
permitted  because  of  the  risk  of  an  untested  program  malfunctioning  or  destroying  critical 
data.  The  system  was  dedicated  for  support  of  development  work  fi'om  1630  to  2400.  This 
resulted  in  the  best  utilization  of  the  computer  system.  This  meant  the  programming  staff  was 
required  to  work  a  less  than  ideal  schedule  -  not  an  uncommon  situation  where  development 
competes  with  production  for  available  computer  resources.  This  utilization  of  the  system, 
shared  by  development  ar  ^rational  activities,  was  most  instrumental  in  meeting  difficult 
programming  objectives  only  minor  impact  on  operations  caused  by  nonavailability  of  the 
system. 

Some  attempts  to  establish  an  operational  capability  had  to  be  aborted  due  to  nonworkability 
in  the  laboratory  sections.  One  attempt  that  failed  was  to  process  laboratory  work  from  a 
single  ward  using  the  system.  The  extra  effort  imposed  by  the  special  case  was  excessive  and 
could  not  be  tolerated.  An  early  version  of  the  system  was  capable  of  supporting  laboratory 
operations  for  a  single  day,  but  no  retention  capability  existed  to  support  carry-over  w'ork. 

'Hie  volume  of  laboratory  work  and  late  arriving  requests  to  be  performed  the  following  day 
made  the  single  day  support  not  acceptable.  Operational  use  had  to  await  the  development  of 
the  full  capabilities  in  retaining  all  specimen  and  accession  status  from  day  to  day.  The 
system  was  required  in  the  laboratory  throughout  the  work  day.  It  was  not  acceptable  to  be 
partially  "on  the  computer"  and  partially  "off,"  It  w'as  not  feasible  to  switch  back  and  forth 
between  two  different  methods. 
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The  magnitude  of  the  transition  from  manual  methods  to  use  of  the  computer  was  much  larger 
than  had  been  anticipated.  From  the  laboratory  viewpoint  this  task  was  equivalent  in  size  to  the 
development  efforts.  L  some  instances  this  became  a  controlling  factor  in  directing  the  subse¬ 
quent  developments.  It  was  deemed  advisable  to  develop  additional  features  for  the  existing 
sections  rather  than  to  develop  new  subsystems  and  procedures  for  other  sections.  The  biggest 
factor  contributing  to  the  difficulty  in  integrating  the  system  was  the  ever-present  demands  on 
the  laboratory.  The  workloads  were  extremely  heavy  throughout  the  integration  period  and 
there  could  be  no  relaxation  in  providing  the  daily  hospital  services.  The  staffing  in  the  labo¬ 
ratory’  was  less  than  optimum,  so  there  was  limited  opportunity  to  learn  the  new  procedures 
and  integrate  these  into  individual  routines. 

Though  the  transition  period  was  difficult  several  advantages  have  accrued  from  implementing 
the  system  in  an  environment  such  as  exists  at  WBGH.  The  broad  range  of  services,  the 
volume  of  activity  and  the  frequency  of  changes  have  exercised  nearly  all  of  the  concepts 
designed  into  the  system.  The  need  for  improvements,  which  only  became  obvious  after  oper¬ 
ational  experience  was  gained,  has  been  identified  in  nearly  all  areas  due  to  the  extensive  use 
of  the  system.  Those  changes  which  were  essential  have  been  put  in  the  system.  Other  changes 
or  additions  can  be  made  to  improve  operations,  but  their  absence  does  not  restrict  reliance 
on  the  system  for  routine  laboratory  support.  The  system  has  received  a  most  rigorous 
exposure  under  actual  conditions.  The  capacity  to  readily  handle  the  loading  during  peak 
periods  has  been  proven.  Evaluation  of  the  prototype  may  proceed  with  the  unique  advantage 
of  an  extensive  operational  experience  base. 


6.2  MILESTONES 

Major  project  achievements  are  shown  below.  Included  are  development  milestones,  equipment 
deliveries,  and  incorporation  of  operational  capabilities. 


Begin  Performance 

Nov. 

1, 

1969 

Complete  Functional  System  Design 

Dec. 

15, 

1969 

Oral  Briefing 

Jan. 

8, 

1970 

Design  Review,  WBGH 

Jan. 

23, 

1970 

Programming  Specifications  Complete 

Feb. 

6, 

1970 

Forms  Design  and  Report  Formats 

Apr. 

1, 

1970 

1800  System  Delivered  to  WBGH 

Apr. 

27, 

1970 

Oral  Briefing 

Apr. 

30, 

1970 

Computer  Building  Complete 

May 

1, 

1970 

Phase  I  Cabling  Complete 

May 

1. 

1970 

Hardware  Installation  Complete 

May 

12, 

1970 

Control  Boxes  Delivered  to  WBGH 

May 

25, 

1970 

Install  Lab  instrumentation  -  Phase  I 

Jun. 

h, 

1970 

Oral  Briefing 

Jul. 

0, 

1970 

Finalize  Mark  Sense  Sheets  ard  Label  Formats 

Aug. 

22, 

1970 

Install  Laboratory  Terminals  (i816's) 

Aug. 

31, 

1970 

Install  1053  Printer 

Sep. 

15. 

1970 

Install  Mark  Sense  Page  Reader 

Sep. 

24, 

1970 

Complete  Development  of  Software  (Ph.  I) 

Oct. 

15, 

1970 

Complete  Package  Testing  (Ph.  I) 

Nov. 

1, 

1970 

Complete  System  Testing  (Ph.  I) 

Dec. 

1. 

1970 

Complete  Audit  (Acceptance)  Testing  (Ph.  I) 

Dec. 

15, 

1970 

Oral  Bi  lefing  -  Phase  I  Demonstration 

Dec. 

17, 

1970 
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Complete  Design  Specifications  for  Flame 
and  Spectrophotofluoi'ometer 
Mark  Sense  Sheets  and  Label  Delivery 
Complete  Design  Specifications  for  Control 

Boxes  for  Differential  Counter,  Fibrometer, 
Coleman  (includes  interface  and  cable 
requirements) 

Initiate  Parallel  Operation  in  Laboratory 
Complete  Instrumentation  Functional  Spec. 
Complete  Instrumentation  Software  Design 
Complete  Package  Testing  (Ph.  H) 

Complete  Functional  Specifications  for  Ward 
Terminals 

Complete  Audit  (Acceptance)  Testing  (Ph.  II) 
Briefing  -  Phase  II  Demonstration 
Initiate  Dedicated  Online  Operation 
Deliver  Four  Control  Boxes  to  WBGI1 
Deliver  Differential  Counter  to  WBGII 
Package  Testing  Instrumentation  Complete 
Complete  2760  Film  Strip  Design 
System  Testing  Instrumentation  Complete 
Install  1403  Printer 
Return  1443  Printer 

IL  Flame,  STAT  Box  Placed  in  Operation 
Three  2740/2760  Terminals  Delivered 
BBL  Fibrometer  Placed  in  Operation 
Engineering  Checkout  Complete  -  3  Terminals 
Package  Testing  Terminals  Complete 
2760  Film  Strips  Delivery 
System  Testing  -  Terminals  Complete 
Keyboard  Delivered  for  Differential  Counter 
Terminal  in  Operation  (Ward  7) 

Engineering  Checkout  Complete  -  2  Terminals 
Differential  Counter  Placed  in  Operation 
Engineering  Checkout  Complete  -  2  Terminals 
Statistics  Package  Completed  and  Placed  in 
Operation 

Remaining  Ward  Terminals  Placed  in  Operation 
Final  Audit  (Acceptance)  Testing 
Final  Oral  Briefing 


6.3  DOCUMENTATION 

Key  documents  produced  during  the  project  de\ elopiuent  are 
mitted  with  this  report). 


System  Design  Report 
Test  Plan 

*  System  Documentation  Package 
Phase  III  System  Specification 
First  Phase  of  the  MILS  Project  -  the 
Laboratory  Information  System 


Doc.  15.  1 070 
Jan.  8,  1971 


Jan.  15,  1971 
Feb.  1 5,  1 971 
Mar.  1,1971 
Apr.  1,  1971 
Apr.  1,  1971 

Apr.  7,  1971 
Apr.  15,  1971 
May  14,  1971 
May  15,  1971 
Jul.  15,  1971 
Aug.  7,  1971 
Sep.  15,  1971 
Oct.  4,  1971 
Oct.  15,  1971 
Oct.  28.  1971 
Nov.  11,1971 
Nov.  13,  1971 
Nov.  16.  1971 
Dec.  10,1971 
Dec.  13.  1971 
Dec.  21,1971 
Jan.  9,  1972 
Jan.  17,  1972 
Feb.  6,  1972 
Feb.  7,  1972 
Feb.  8,  1972 
Feb.  12,  1972 
Feb.  14,1972 

Mar.  1,  1972 
Mar.  15,  1972 
Mar.  28,  1972 
Mar.  30,  1972 


summarized  below  (not  resub- 


January  1970 
June  1 970 
December  1970 
April  1971 

May  1971 
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♦System  Documentation  Package  May  1971 

Cost  Analysis  Report  August  15,  1971 

Development  Status  Reports  were  submitted  monthly 
Memoranda  describing  extensions  in  the  operational 
system  were  distributed  as  upgrades  were 
released. 


6.4  EXPERIENCES 

As  implementation  progi’essed  toward  complete  reliance  on  the  system,  it  became  necessary 
to  make  changes  in  the  equipment  configuration  and  operational  procedures.  The  "real-world" 
experience  pointed  out  the  need  to  deviate  from  the  original  plan  to  more  effectively  support 
the  day  to  day  operations. 


6.4.1  1403  Printer 

The  original  configuration  included  a  1443  line  printer  (250  1pm)  for  large  volume  patient  and 
laboratory  reports.  A  27S0  line  printer  was  to  be  installed  for  remote  printing  of  outpatient 
reports  in  a  central  location  where  these  reports  could  be  readily  distributed. 

As  operational  use  increased  it  became  desirable  to  print  the  cumulative  report  as  the  final 
daily  patient  report  and  to  distribute  it  to  the  wards  by  4:30  P.M.  The  daily  log  showing  all 
status  for  the  day  (patients,  locations,  requests,  results,  accession  numbers)  was  needed  by 
the  second  shift  personnel  who  began  work  at  4:30  P.M.  It  was  desirable  to  delay  report 
printing  as  long  as  practical  in  order  to  have  the  latest  completions  reflected  in  the  report. 

In  order  to  meet  the  objective  of  large  print  volumes  compressed  into  short  time  spans  the 
1100  line  per  minute  1103  printer  was  installed.  This  enabled  cumulative  reports  to  be  printed 
within  the  time  constraints.  The  2780  remote  printer  was  deleted  from  the  configuration  and 
the  print  load  projected  for  this  device  was  assumed  by  the  higher  performance,  local  line 
printer.  The  net  affect  on  the  overall  equipment  configuration  was  a  reduction  in  equipment 
costs. 


6.4.2  STAT  Entry  Box 

The  original  plans  for  the  online  instrumentation  complex  included  the  Coleman  II.  A  control 
box  was  designed  and  built  and  the  interface  for  data  acquisition  was  established.  Attempts  tu 
utilize  the  signal  for  result  determination  showed  that  an  impedance-match  problem  existed 
between  this  instrument  and  the  computer.  Data  transmitted  was  not  sufficiently  reliable  for 
result  determination.  The  problem  could  have  been  solved  by  adding  electronics  to  provide 
immediate  amplification.  The  delay  which  would  have  been  introduced  for  procurement  of 
additional  components  and  the  laboratory's  desire  to  use  the  control  box  for  other  purposes 
resulted  in  the  removal  of  this  instrument  from  the  online  complex.  The  control  box  was  con¬ 
verted  to  serve  as  a  direct  entry  for  digital  results.  New  programs  were  written  to  support 
this  function  and  the  device  was  placed  in  operation  in  the  Chemistry  Laboratory.  Later,  when 
a  separate  STAT  laboratory  was  set  up  in  the  WBGI1  laboratory,  the  device  was  moved  to  this 
location.  This  has  eliminated  mark  sensing  these  results  for  computer  processing.  STAT's 
art,  transmitted  directly  to  on-ward  terminals  when  they  have  been  completed.  The  direct 
entry  of  offline  results  and  immediate  transmission  to  the  requesting  service  has  significantly 
enhanced  the  laboratory's  response, 

♦Those  documents  are  obsoleted  by  this  report. 
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Digital  Input  Special  Feature 

I'hc  initial  set  of  instruments  and  control  boxes  (SMA,  AA’s  and  Coulter  Counter)  was 
installed  with  a  direct  line  for  every  digital  input  point  (one  line  per  bit).  When  the  next  set 
of  online  instruments  (5)  and  control  box  requirements  were  defined,  the  requirement  for  a 
large  number  of  cables  and  digital  input  points  on  the  1800  was  reviewed.  An  alternate 
approach  which  uses  an  1800  feature.  Digital  Input  Special,  was  selected.  This  feature  pro¬ 
vides  a  multiplexing  of  the  various  devices  over  common  lines  into  a  common  digital  input 
group  on  the  1800.  One  group  of  ECO  (Digital  outputs)  is  used  and  the  desired  input  group 
(10  bits)  is  selected  under  program  control  using  an  ECO  bit  pattern  to  uniquely  define  the 
input  lines  which  will  transmit  on  the  next  ’’READ."  Economies  have  resulted  in  both  the 
amount  of  cabling  required  and  the  number  of  digital  input  groups  installed  on  the  1800.  No 
degradation  in  user  response  results  from  this  multiplexing  of  digital  inputs. 


0.4.4  Ward  20  Terminal 

One  of  the  project  objectives  was  to  install  a  single  clinical  terminal  early  in  the  operational 
poriod.  A  1053  character  printer  was  installed  in  Ward  26  to  meet  this  objective.  Programs 
wero  writton  to  retriove,  format,  and  transmit  pationt  reports  on  domnnd  to  this  Ward  20 
tormina).  When  tho  laboratory  began  logging  all  work  (inpatients  and  outpatients)  into  tho 
system,  the  local  terminal  did  not  have  sufficient  capacity  to  handle  tho  poak  load  labol  prepa¬ 
ration  which  occurred.  The  immediate  solution  to  this  situation  was  to  "steal"  the  printor, 
which  had  been  installed  for  patient  reports,  from  Ward  20  and  reassign  it  in  the  Lab  Recep¬ 
tion  aroa  as  a  dedicated  label  printer.  This  extra  print  capacity  enabled  the  entry  of  all 
inpatient  and  outpatient  test  requisitions  and  the  plan  for  phasing  the  system  Into  dedicated 
operational  use  remained  on  target.  In  checking  back  to  determine  tho  sourco  of  tho  initial 
design  oversight,  two  factors  were  discovered.  Though  the  estimates  of  total  laboratory  volume 
wore  sufficiently  accurate,  there  were  significantly  fewer  collections  than  had  boon  anticipated.  V. 
This  meant  more  inpatient  work  was  generating  non-collection  labal  printing  than  had  been 
anticipated.  The  other  factor  was  the  method  of  delivery  of  outpatient  specimens.  Frequently 
tho  clinics  delivered  largo  batches  of  specimens  to  the  laboratory.  These  heavy  workloads  are 
generated  for  short  bursts  of  timo  rather  than  being  evenly  distributed.  Additional  capacity 
was  necessary  during  label  preparation  so  os  not  to  delay  test  performance  at  the  laboratory 
work  stations. 


0.4.5  Admission  and  Discharge  (A&D) 

Tho  original  dosign  specified  installation  of  a  terminal  for  entry  of  admission  and  discharge 
data  in  the  admissions  office.  A  keyboard  terminal  was  installed  for  this  purpose  but  the 
occurrence  of  operational  problems  resulted  in  transfer  of  this  function  to  the  laboratory 
reception  area. 

One  recurring  problem  was  caused  by  requests  for  inpatient  work  arriving  at  tho  laboratory 
in  cases  where  no  records  for  the  patients  had  been  established.  Lab  Receptionists  would 
"admit"  the  patients  so  the  requisition  could  be  processed.  Later,  when  the  A&D  clerk  would 
attempt  the  admission  the  system  would  respond  with  notification  that  the  patients  were 
already  in  the  system.  Tins  caused  confusion  for  the  A&D  clerk  as  to  the  overall  status  of 
patient  admissions. 

At  the  time  the  terminal  was  located  in  the  A&D  Office,  the  system  was  online  for  only  ono 
shift.  The  system  was  supporting  development  activities  on  second  shift  and  the  third  shift 


operator  had  not  yet  been  employed.  Consequently,  the  system  was  not  always  available  when 
A&D  personnel  resources  could  have  been  used  to  perform  this  function. 

The  online  realtime  entry  of  admission  data  from  the  Admission  Office  is  the  most  desirable 
system  approach  for  recording  patient  identification.  The  need  for  timely  entry  is  especially 
reinforced  when  ward  terminals  are  installed  and  nurses  make  bed  assignments  and  lab 
requests  using  the  terminal.  These  patient  references  on  the  ward  can  be  accomplished  only 
after  the  basic  admission  data  is  established  in  the  system.  Factors  necessary’  for  successful 
use  of  a  terminal  in  the  A&D  Office  include: 

a.  Sole  responsibility  in  A&D  for  entry  of  admission  and  disposition  data. 

b.  Sufficient  personnel  time  must  be  available  to  perform  the  function. 

c.  The  terminal  must  be  online  for  extensive  periods  (at  least  16  hours  per 
day)  on  a  regularly  scheduled  basis. 


6.4.6  Terminal  Configuration 

The  original  design  called  for  installations  of  11  2740/2760  terminals  in  the  nursing  stations. 
This  device  was  selected  because  it  provided  ease  of  use,  hard  copy  transaction  records,  and 
could  be  expanded  for  other  functions.  The  projection  of  film  strip  data,  light  pen  type  probe, 
a  large  number  of  possible  inputs  and  program-controlled  frame  movement  fulfilled  the  ease- 
of-use  objective.  Large  numbers  of  nurses  and  doctors  could  thus  learn  the  terminal  opera¬ 
tion  with  limited  instruction  and  hands-on  training. 

Midway  through  the  project,  but  before  software  had  been  developed,  a  new  terminal  was 
announced  which  was  compatible  with  the  1800  System— the  3270.  This  new  terminal  offered 
the  lastest  technology,  had  all  of  the  attractive  features  offered  by  the  2740/2760,  had  higher 
rates  of  data  transmission,  reduced  overhead  on  the  CPU,  had  improved  performance  through 
CRT  and  faster,  silent  printing,  and  was  less  expensive.  This  device  was  placed  on  order  as 
soon  as  the  product  was  announced.  All  efforts  were  made  to  procure  this  terminal  in  time 
to  meet  project  schedule  commitments.  However,  IBM  production  schedules  could  not  be  suf¬ 
ficiently  improved  to  meet  the  project  deadlines.  It  was  not  desirable  to  defer  project  schedules 
and  plans  were  redirected  to  implement  the  2740/2760s. 

The  final  review  of  the  configuration,  considering  the  move  to  the  new  facility,  resulted  in 
selection  and  installation  of  seven  ward  terminals.  These  have  been  placed  in  operation  and 
the  U.S.  Army  objective  of  developing  an  experience  base  prior  to  moving  into  the  new  facility 
in  July,  1972  is  being  realized. 
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Section  7.  FUTURE  DEVELOPMENTS 


The  nature  of  online  EDP  systems  is  that  they  do  not  remain  static.  Implementation  of  one 
feature  generates  the  requirement  for  additional  features.  As  operational  experience  is 
gained  with  existing  features,  ideas  evolve  where  increased  efficiency  and  productivity  can 
result.  Full  value  of  the  system  is  realized  when  progressive  steps  are  continually  taken 
toward  accomplishment  of  these  objectives.  The  MILS  prototype  can  be  profitably  extended 
through  increased  data  reduction  and  analysis,  by  extending  the  scope  of  present  design  to 
include  additional  applications  and  by  making  available  additional  operator  options. 


7.1  DATA  REDUCTION  AND  ANALYSIS 

Listed  following  are  some  areas  where  data  reduction  and  analysis  programming  will  provide 
added  decision-making  information  for  increased  effectiveness.  The  basic  data  is  presently 
available  in  either  the  online  disk  files  or  in  the  history  files  written  on  magnetic  tape. 

a.  Analysis  and  exception  reports  of  abnormal  values 

b.  Comparison  of  today's  results  with  previous  results  and  exception  reports 
where  deviations  are  excessive 

c.  Summary  of  all  lab  work  prepared  on  patient  discharge 

d.  Statistical  computations  and  summary  of  results  by  test  and  age  groups 

e.  Analyses  of  sendees  provided  to  the  various  requesting  agencies. 


7.2  ADDITIONAL  APPLICATIONS 

MILS  has  been  designed  and  developed  using  modular  concepts.  The  approach  was  taken  to 
allow  incorporation  of  new  programs  and  to  provide  a  facility  to  change  existing  ones  at  the 
installation. 

The  changes  and  extensions  can  be  made  on  site  by  user  personnel,  following  the  modular 
concept  for  introduction  of  new  programs.  The  incorporation  of  changes  involves  identifying 
the  appropriate  module(s),  making  the  program  changes,  and  using  the  DMP  (Disk  Manage¬ 
ment  Program)  to  replace  the  old  program  with  the  new. 

The  computing  capacity  of  the  1800  can  be  utilized  to  execute  jobs  which  may  be  related  to 
or  completely  independent  of  the  laboratory.  These  programs  would  be  initiated  under  oper¬ 
ator  control  to  execute  in  the  background  using  available  CPU  time.  These  pi’ograms  are 
assigned  ihe  lowest  system  priority  so  there  is  no  interference  with  the  online  realtime 
functions.  These  programs  may  be  placed  in  the  program  residence  library,  using  the  Disk 
Management  Program  to  eliminate  any  handling  of  program  decks  and  loading  via  a  card 
reader. 

There  are  many  applications  where  the  extension  of  EDP  utilization  will  contribute  to 
improved  information  handling.  The  clinical  laboratory  has  made  the  most  significant 
advancements  in  the  application  of  EDP  in  their  routine  operations.  Other  professional 
services  are  being  confronted  with  the  same  kind  of  situations,  i.e-.  increasing  workloads, 
decreases  in  clerical  staff,  more  and  more  demands  for  information  sooner  and  from  multiple 
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sources,  and  technology  advancements  creating  information  at  increasing  rates.  All  of  these 
factors  contribute  to  the  requirement  for  machine  collection,  organization,  storage,  retrieval 
and  presentation  of  data  to  support  the  clinical  decision  making.  Candidates  for  EDP  use 
include,  but  are  not  necessarily  limited  to,  ECG  Analysis,  Radiology,  Patient  Monitoring, 
Dietary, -Patient  Assessment, -Outpatient  scheduling  and  problem  oriented  patient  re'cTTT'tte. 


7.3  OPERATIONAL  SUPPORT 

Areas  where  operational  improvements  will  result  depend  on  the  needs  at  specific  installations. 
Some  extensions  have  been  determined  as  being  desirable  at  WBGII.  These  can  be  added  to  the 
existing  system  as  resources  are  available,  and  plans  for  operational  implementation  evolve. 
Adding  the  bacteriology  and  serology  tests  to  the  operational  set  will  complete  clinical  labo¬ 
ratory  automation  at  WBGH.  The  blood  bank  automation  can  be  accomplished  using  a  phased 
approach.  A  batch  processing  mode  of  operation  using  tape  files  would  provide  the  blood  bank 
with  quick-look  donor  acceptability  checks,  emergency  donor  lists  and  statistical  breakdowns 
including  transfusion  records  by  patient  and  service. 

The  online  instrumentation  complex  can  be  augmented  to  include  other  instruments  as  they  are 
installed  and  placed  into  operation.  The  most  probable  candidates  at  WBGH  are  a  4-channel 
electrolyte  system  and  a  3-channel  enzymes  system.  The  interaction  with  A&D  may  be 
improved  with  the  additional  method  of  patient  data  entry  through  a  punched  card  deck.  Opera¬ 
tional  experience  has  shown  that  patient  location  on  the  lab  result  sheets  and  specific  test 
requested  noted  on  the  specimen  retention  report  will  provide  data  for  added  convenience  of 
the  technicians.  The  ability’  to  input  all  control  box  data  through  the  keyboards  will  add  a 
measure  of  reliability.  A  malfunction  in  the  control  box  will,  thus,  not  disable  the  online  data 
acquisition.  Selective  reprints  of  collection  schedules  will  enhance  the  recovery  procedures 
when  a  line  printer  failure  occurs  during  schedule  preparation. 
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Section  8.  CONCLUSIONS 


Programming  modules  have  been  developed,  tested  and  integrated  into  a  unified'  Laboratory 
Information  System  functioning  in  a  realtime  environment  as  a  single  operating  unit.  Several 
months  of  operational  use  have  provided  the  thorough  shakedown  necessary  to  disclose  required 
refinements  and  gain  operational  experience  and  confidence.  The  extensive  operational  use  has 
validated  MILS  design  concepts. 

The  value  of  the  multiprogramming  approach  has  been  proven.  The  facility  to  add  or  update 
program  modules  within  the  existing  architecture  is  used  on  repeated  occasions.  CPU  pro¬ 
cessing  of  multiple  tasks,  simultaneously,  is  common  during  ordinary  operations.  Data  Acqui¬ 
sition,  Data  Analysis,  Test  Requisition,  Laboratory  Communications  and  Ward  Communication 
are  frequently  active  all  at  the  same  time.  To  attain  this  degree  of  processing  effectiveness, 
data  organization  that  permits  rapid  storage  and  retrieval  of  any  item  must  be  included. 

Design  of  the  MILS  information  base  meets  this  criteria.  The  resulting  throughputs  meet  the 
strict  response  standards  necessary  for  user  acceptance. 

A  design  which  permits  changes  in  the  test  repertory,  procedure  assignments,  reporting 
formats,  and  laboratory  methods  is  both  valuable  and  necessary.  A  system  which  supports  all 
phases  of  the  laboratory  test  cycle  must  be  adaptive  to  the  dynamics  uf  the  laboratory  environ¬ 
ment— this  means  frequent  changes  are  routinely  required  and  a  flexible  design  must  accom¬ 
modate  this  mode  of  operation. 

The  system  evaluation  may  be  conducted  in  an  operational  setting  under  actual  field  conditions. 
Modifications  may  be  implemented  on  a  trial  basis  with  decisions  on  final  acceptability 
deferred  until  operational  use  is  accomplished. 

The  anticipated  efficiencies  in  clerical  functions  have  been  realized  through  automating  the 
laboratory  information.  Improvements  in  operations  have  resulted  from  saved  man  hours 
which  can  now  be  applied  to  non-clerical  responsibilities.  Improvements  in  accounting  and 
specimen  control  contribute  to  the  laboratory  effectiveness  and  improved  service.  Savings 
which  can  be  directly  measured  in  man  hours  due  to  elimination  or  reduction  of  these  manual 
tasks  are: 

a.  Sorting  requisitions  for  ward  rounds 

b.  Construction  of  work  lists 

c.  Calculation  of  results 

d.  Recording  results  and  maintenance  of  the  log 

e.  Copy,  sorting  and  filing  data  sheets 

f.  Manual  sorting  for  specimen  discard 

g.  Tabulating  statistics 

h.  Production  of  quality  control  records 

i.  Telephone  inquiries  from  requesting  services. 

Additional  advantages  are  realized  through  system  use.  Although  not  as  easily  measured,  they 
do  contribute  to  the  common  mission  of  improved  patient  care: 

a.  Reduction  in  lost  requisitions 

b.  Reduction  in  specimen  redraws 
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c.  Fewer  requisitions  repeated 

d.  Improved  legibility  resulting  from  machine  printouts 

e.  Elimination  of  transcription  errors 

f.  Standardization  in  specimen  drawing,  turntable  set-ups,  and  result  reporting 

g.  Possible  excess  of  requests  can  be  detected 

h u..  .Trends  readily  identifiable  through  history  reports 

i.  Effect  of  treatment  readily  apparent 

j.  Lab  results  consolidated  on  one  sheet 

k.  Faster  interpretation  of  results  is  possible 

l.  Specimen  disposition  can  be  accomplished  sooner 


m.  Status  of  lab  work  known  at  any  time. 


The  scope  of  the  system  may  be  expanded  to  support  additional  applications— either  laboratory 
related  or  pertaining  to  other  hospital  areas.  EDP  has  historically  been  used  in  support  of 
hospital  administrative  functions.  The  increase  in  demands  for  services,  personnel  shortages 
and  instrumentation  technology  advancements  produce  the  requirement  for  automated  infor¬ 
mation  handling  in  the  laboratory.  Solving  the  problem  for  the  clinical  laboratory  is  only  an 
introductory  step  in  support  of  Professional  Services.  The  design  concepts  built  into  MILS 
have  taken  into  consideration  expansion  into  other  Professional  Service  areas.  Patient  identi¬ 
fication  is  maintained  in  a  master  file  with  "pointers"  to  the  laboratory  records.  All  labora¬ 
tory  files  (patients,  tests,  specimens,  quality  control,  etc.)  are  contained  in  the  laboratory 
module.  This  data  base  may  be  expanded  in  modules  to  serve  other  professional  needs 
(Patient  History,  Radiology,  Nursing,  Pharmacy,  etc.).  Pointers  can  be  added  for  compatibility 
with  this  patient-oriented  organization  as  other  modules  are  introduced. 


The  architecture  further  provides  for  simultaneous  processing  of  multiple  operations.  The 
information  will,  thus,  be  current  and  can  be  produced  on  demand  for  the  hospital  staff.  Diag¬ 
nostic  decisions  can  be  made  using  machine  correlations  of  information  from  independent, 
yet  clinically  related,  sources. 
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Order  Number 


25. 

GA24-3435 

26. 

GA27-3011 

27. 

GA24-3073 

28. 

C20-1668 

29. 

C30-2007 

30. 

GA24-3090 

31. 

L26-2112 

32. 

GX26-3573 

33. 

GA27-3006 

34. 

GX26-3780 

35. 

GX26-5624 

36. 

GX26-1594 

Title 

Planning  and  Installation  of  a  Data  Communications  System 
Using  IBM  Line  Adapters 

IBM  2760  Optical  Image  Unit  Component  Description 

IBM  1403  Printer  Component  Description 

Data  Communications  Primer 

IBM  System  360 

Introduction  to  Teleprocessing 

IBM  Teleprocessing  System  Summary 

Start/Stop  Teleprocessing  Adapter  General  Information  Manual 
RPQ  C08763 

IBM  1800  Data  Acquisition  and  Control  System— Physical 
Planning  Template 

IBM  Remote  Multiplexers  and  Communications  Terminals 
Installation  Manual— Physical  Planning 

IBM  1130/1800  Assembler  Language  Statements  Summary 

IBM  1800  Reference  Summary  System  Reference  Data 

IBM  1800  Reference  Summary  MPX  Control  Statements 
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Appendix  B 


MILS  OPERATING  SCHEDULE 


Time 

0000-0100 

0100-0200 

0200 

0530 

0000 

00-15 

0715 

0730 

0830 

0800 

0000 

1200 


Tuesday  -  Friday  Procedure 

Dump  system  files  (2311)  on  backup  tape 

Gather  backlog,  enter  requisitions,  and  results  if  work 
complete 

Do  file  maintenance  for  previous  day 
Reinitialize  system  for  current  day 
Start  2740/2700  terminals 
Print  inpatient  roster 
Run  instrumentation  diagnostic:: 

Initiate  log-in  of  current,  laboratory  work  as  it  arrives 
Obtain  requests  for  ward  round  collection 
Transcribe  and  enter  ward  round  requests 

Print  labels  for  ward  round  collectors  and  set  out  labels  for 
collection  ter.m 

Print  specimen  retention  reports  for  use  during  collection 
verification 

Obtain  current  admission  data  and  enter  new  admissions 
Print  updated  alpha  inpatient  roster 

Lab  technologists  begin  system  use— instruments,  lists,  result 
entry,  etc.  'Fins  continues  throughout  the  day 

Print  first  midday  reports  for  selected  wards  (e.g.,  ICU) 

Verify  ward  round  collection  as  collectors  return 

Assign  "cut-off"  number  for  Chemistry  Section  when  all 
collectors  have  returned  (procedural  only) 

Obtain  and  save  workload  reports— all  sections 

Chief,  MILS  reviews  previous  day  outpatients  reports,  files 
for  distribution 

Obtain  quality  control  results  from  previous  day  for  offline 
tests 

I’pdate  quality  control  card  file  for  offline  tests 
Print  offline  Quality  Control  Report 
Print  online  Quality  Control  Report 
Distribute  Q.C.  reports  to  sections 

Obtain  and  save  workload  reports  for  all  sections 

Print  midday  inpatient  reports  (provided  morning  SMA  run  is 

complete) 

Chief,  Clinical  Path  reviews  reports  and  has  them  distributed 
to  wards 
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Time 

1230 

1300 

1400 

1430 

1500 

1530 

1600- 

1900 

2000- 


Tuesday  -  Friday  Procedure 


Print  outpatient  log 

Enter  patient  discharges 

Midday  reports,  selected  wards  (medicine) 

Print  outpatient  log 

Print  midday  reports 
Pathologist  review  and  distribute 

Generate  labels  for  Cardiology  Clinic  outpatients  to  be  seen 
the  following  morning  (names  of  patients  supplied  by 
Cardiology  Clinic) 

Get  count  of  day's  requisitions  and  file  request  slips 

•1900  Log  in  laboratory  requests 

Print  Cumulative  Inpatient  Reports.  Outpatient  Reports.  Daily 
Log.  Specimen  Retention.  Daily  Lab  Summary 

2400  Laboratory  is  offline— System  is  available  for  development 

purposes 


Procedure  for  Monday 
Cold  start  as  previous  day 

Obtain  and  save  workload  reports  for  all  sections 
Build  final  inpatient  and  outpatient  reports 
Perform  file  maintenance 
Obtain  and  save  world oad  reports 
Stop  system 

Cold  start  as  correct  day 

(Continue  from  point  of  starting  2740/2760  terminals) 


Procedure  for  Weekend 

Cold  start  as  previous  Friday 

Obtain  and  save  workload  reports  for  all  sections 

Build  and  print  non-final  outpatient  reports. 

(These  will  be  reviewed  and  distributed  the  following  Monday) 
Build  final  outpatient  reports 

Print  outpatient  logs  and  specimen  retention  reports  and 

distribute  to  lab  sections 

Perform  file  maintenance 

Obtain  and  save  workload  reports 

Stop  system 

Cold  start  as  Saturday 
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Procedure  for  Weekend 


Log  in  routine  requests  received  during  Saturday 
Build  final  inpatient  and  outpatient  reports 
Print  inpatient  and  outpatient  logs  and  distribute  to  lab 
sections 

Print  final  inpatient  reports  if  necessary  (contingent  upon 
degree  of  completeness  of  reports  printed  on  previous 
Friday). 

Review  and  file  for  distribution  if  reports  are  printed 

Perform  file  maintenance 

Stop  system 

Cold  start  as  Sunday 

Log  in  routine  requests  received  during  Sunday 
Stop  system 
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